Race Conditions in DDK Bulk USB Sample Driver ??

NTDEV
1

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

2

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

3

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’)