kernel - Fix network lockup due to msgport bug
authorMatthew Dillon <dillon@apollo.backplane.com>
Fri, 22 Feb 2013 02:14:45 +0000 (18:14 -0800)
committerMatthew Dillon <dillon@apollo.backplane.com>
Fri, 22 Feb 2013 02:14:45 +0000 (18:14 -0800)
commitddb06db22c9a473b5bbb374b988cd074eda75a80
treebef47d2733a5f372dcdb2289d4bbdec15a255f81
parent7eb18c8e34ad4dee1c7ab862a153ed444fdf3854
kernel - Fix network lockup due to msgport bug

* Netisr threads (i.e. arp thread) which issue route table updates
  use a synchronous netmsg from a 'spin' type port to a 'thread' type
  port.

  When going spin->thread, the lwkt_thread_putport*() code was not
  using an atomic op to manipulate ms_flags.  This could interfere
  with the originator on the spin port issuing a lwkt_spin_waitmsg()
  and cause one or more flags to be lost.

  Ensure that lwkt_thread_putport*() uses atomic ops when manipulating
  ms_flags.

* Another serious issue is that the lwkt_*_waitmsg() code was testing
  MSGF_QUEUED outside of its port lock.  This flag can only be tested
  while the port is locked.

* lwkt_thread_replyport() must use an atomic op when setting
  MSGF_INTRANSIT and MSGF_REPLY to avoid SMP races on ms_flags
  updates.

* lwkt_thread_replyport() requires a critical section against
  possible preemption when adjusting ms_flags.

* lwkt_forwardmsg() does not need a critical section.

* Other notes: Not all ms_flags manipulation needs an atomic op.  For
  example, when initializing a new message or when a lock is held to
  rendezvous at a reply port when replying.  However, all 'put' and 'wait'
  interactions on messages absolutely require atomic ops when manipulating
  ms_flags.

  Finally, note that all msgport queue operations use atomic ops to
  adjust MSGF_QUEUED when adding or removing a message to a port queue.
sys/kern/lwkt_msgport.c