I have been looking at how the DDK bulkusb example handles Stopping and
Removal of devices and think I see a race condition.
It looks as if the code calls BulkUsb_CanAcceptIoRequests() before it
processes any IRPs. The purpose of this function is to check some status
flags in the device extension that are set by the PnP Stop/Remove/Query
logic.
The code looks like this:
if ( !deviceExtension->DeviceRemoved &&
// device must be started( enabled )
deviceExtension->DeviceStarted &&
// flag set when driver has answered success to
IRP_MN_QUERY_REMOVE_DEVICE
!deviceExtension->RemoveDeviceRequested &&
// flag set when driver has answered success to
IRP_MN_QUERY_STOP_DEVICE
!deviceExtension->StopDeviceRequested ){
fCan = TRUE;
Now:
What if while in the middle of these checks, say after the
RemoveDeviceRequested flag is checked the driver recieves a
IRP_MN_QUERY_REMOVE_DEVICE request and the flag gets set to true. (The
PnP code simply checks to see if there are any outstanding IRPs via a
counter, and if there are none it tells the PnP manager that it is OK to
remove the device and sets the RemoveDeviceRequested flag). Once this
happens, our I/O request will continue since we have already checked
this flag.
Am I missing something here ??
Thanks !
-Chris
This may be the simplistic answer, but isn’t this what spinlocks are for?
KeAcquireSpinLock(&deviceExtension->serialize, &oldIrql);
… your if clause
KeReleaseSpinLock(&deviceExtension->serialize, &oldIrql);
This should synchronize access to those flags, given that the code that
handles QUERY attempts to acquire the same spinlock.
-----Original Message-----
From: Christopher Pane [mailto:xxxxx@vanteon.com]
Sent: Friday, June 16, 2000 12:17 PM
To: NT Developers Interest List
Subject: [ntdev] Race Conditions in DDK Bulk USB
Sample Driver ??
<< File: Card for Christopher Pane >> I have been looking
at how the DDK bulkusb example handles Stopping and
Removal of devices and think I see a race condition.
It looks as if the code calls BulkUsb_CanAcceptIoRequests()
before it
processes any IRPs. The purpose of this function is to check
some status
flags in the device extension that are set by the PnP
Stop/Remove/Query
logic.
The code looks like this:
if ( !deviceExtension->DeviceRemoved &&
// device must be started( enabled )
deviceExtension->DeviceStarted &&
// flag set when driver has answered success to
IRP_MN_QUERY_REMOVE_DEVICE
!deviceExtension->RemoveDeviceRequested &&
// flag set when driver has answered success to
IRP_MN_QUERY_STOP_DEVICE
!deviceExtension->StopDeviceRequested ){
fCan = TRUE;
Now:
What if while in the middle of these checks, say after the
RemoveDeviceRequested flag is checked the driver recieves a
IRP_MN_QUERY_REMOVE_DEVICE request and the flag gets set to
true. (The
PnP code simply checks to see if there are any outstanding
IRPs via a
counter, and if there are none it tells the PnP manager that
it is OK to
remove the device and sets the RemoveDeviceRequested flag).
Once this
happens, our I/O request will continue since we have already
checked
this flag.
Am I missing something here ??
Thanks !
-Chris
I agree the need for sychonization, I was just surprised there was none in the
Sample in the DDK ;->
Later
-Chris
Gary Little wrote:
This may be the simplistic answer, but isn’t this what spinlocks are for?
KeAcquireSpinLock(&deviceExtension->serialize, &oldIrql);
… your if clause
KeReleaseSpinLock(&deviceExtension->serialize, &oldIrql);
This should synchronize access to those flags, given that the code that
handles QUERY attempts to acquire the same spinlock.
-----Original Message-----
From: Christopher Pane [mailto:xxxxx@vanteon.com]
Sent: Friday, June 16, 2000 12:17 PM
To: NT Developers Interest List
Subject: [ntdev] Race Conditions in DDK Bulk USB
Sample Driver ??
<< File: Card for Christopher Pane >> I have been looking
at how the DDK bulkusb example handles Stopping and
Removal of devices and think I see a race condition.
It looks as if the code calls BulkUsb_CanAcceptIoRequests()
before it
processes any IRPs. The purpose of this function is to check
some status
flags in the device extension that are set by the PnP
Stop/Remove/Query
logic.
The code looks like this:
if ( !deviceExtension->DeviceRemoved &&
// device must be started( enabled )
deviceExtension->DeviceStarted &&
// flag set when driver has answered success to
IRP_MN_QUERY_REMOVE_DEVICE
!deviceExtension->RemoveDeviceRequested &&
// flag set when driver has answered success to
IRP_MN_QUERY_STOP_DEVICE
!deviceExtension->StopDeviceRequested ){
fCan = TRUE;
Now:
What if while in the middle of these checks, say after the
RemoveDeviceRequested flag is checked the driver recieves a
IRP_MN_QUERY_REMOVE_DEVICE request and the flag gets set to
true. (The
PnP code simply checks to see if there are any outstanding
IRPs via a
counter, and if there are none it tells the PnP manager that
it is OK to
remove the device and sets the RemoveDeviceRequested flag).
Once this
happens, our I/O request will continue since we have already
checked
this flag.
Am I missing something here ??
Thanks !
-Chris
You are currently subscribed to ntdev as: xxxxx@vanteon.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)