Re: DDK sample bug reporting by BubbaGump
BubbaGump
Fri Dec 22 07:49:49 CST 2006
On Thu, 21 Dec 2006 19:47:19 -0800, "Doron Holan [MS]"
<doronh@nospam.microsoft.com> wrote:
>you can use one of hte ddk feedback links on a WDK page that relate to the
>sample (if there is one). what is the bug you want to report?
What I noticed is in the toaster bus sample (starting from the
DriverEntry in general\toaster\bus\busenum.c). In a couple cases it
orders its custom remove lock operations backwards, which are race
conditions.
For IRP_MJ_PNP and IRP_MJ_POWER it tests
DevicePnPState first but waits until a little later to call
Bus_IncIoCount. This is a test-and-set race. In the time between the
test on the state and the increment of the count, an
IRP_MN_REMOVE_DEVICE could have been handled, seen from the old count
that the device wasn't in use, and proceeded with removal just as the
handler for IRP_MJ_PNP and IRP_MJ_POWER was beginning to run.
(The operations are ordered the safe set-first-then-test way for
IRP_MJ_CLOSE, IRP_MJ_DEVICE_CONTROL, and IRP_MJ_SYSTEM_CONTROL, which
is ironic since these are the IRPs that shouldn't happen during/after
removal for other reasons.)
While I was looking at this, I also noticed a Bus_DecIoCount missing
from the (DevicePnPState == Deleted) error cleanup of the IRP_MJ_CLOSE
handler. Although it may be unnecessary to use a remove lock for
IRP_MJ_CLOSE, if the example usage were used elsewhere then it could
prevent a device from ever being removed if it happened while the
driver was handling IRP_MN_REMOVE_DEVICE during the time when it would
have blocked new requests and would be waiting for current requests to
finish.