Fix an insufficient test of the message flags when determining whether
authorMatthew Dillon <dillon@dragonflybsd.org>
Wed, 4 Jul 2007 23:36:26 +0000 (23:36 +0000)
committerMatthew Dillon <dillon@dragonflybsd.org>
Wed, 4 Jul 2007 23:36:26 +0000 (23:36 +0000)
commitebe43e155413eac55f1a8a1155959203cab8fc75
tree16407028e261d7d3bef1068febb27dbb118d8884
parent5288fd4c73e1dd954669a0842c3f2ff02c657f6a
Fix an insufficient test of the message flags when determining whether
an abortable request has already completed or not.

Abort requests are sent to the same port as the original message which
means that the original message will have been processes and either replied
to or queued before the abort message is acted upon.  However, when an
abort message is replied the MSGF_DONE bit is *NOT* set until the reply
reaches the reply port, potentially requiring an IPI.

This can lead to a race where the code processing an abort request
incorrectly determines that the message has not yet been replied when in
fact it has, leading to a double-reply and a panic.

The solution is to test the MSGF_REPLY bit, which is set by the target
cpu (the one processing the original message) when replying to the message
prior to issuing any IPI.

Reported-by: Peter Avalos <pavalos@crater.dragonflybsd.org>
Dragonfly-bug: <http://bugs.dragonflybsd.org/issue717>
sys/kern/uipc_msg.c