A sort of "query remove lock"?
in [Device Drivers]
|
From: BubbaGump on 7 Oct 2006 14:59 I see, another good part about pairing a file handle with an interface reference is it should stop the remove IRP from ever being sent so the remove IRP handler wouldn't wait forever because it wouldn't even be called until the interface was released (assuming everyone plays by the rules). On Fri, 6 Oct 2006 20:45:29 -0700, "Alexander Grigoriev" <alegr(a)earthlink.net> wrote: >Af a third driver holds an interface reference, it's a good idea if it also >held a FILE_OBJECT to the target device. This also allows to register for >query remove request. > ><BubbaGump> wrote in message >news:ls4di2hul4m63hq736pvcoh179llrat0hk(a)4ax.com... >> ...forever...unless there's some way to notify whoever has references >> to the interface to please release it? >> >> >> >> >> On Fri, 06 Oct 2006 12:52:02 -0400, BubbaGump <> wrote: >> >>>What about the REMOVE_DEVICE that follows the SURPRISE_REMOVAL? That >>>must be held forever until the interface is released, since it might >>>allow the unload of the code and data to which the interface refers. >>> >>> >>> >>> >>>On Fri, 6 Oct 2006 12:43:53 -0400, "Don Burn" <burn(a)stopspam.acm.org> >>>wrote: >>> >>>>It can fail all the requests to the interface currently in progress and >>>>issued in the future, it can not hold the SURPRISE_REMOVAL forever. >> >
From: BubbaGump on 7 Oct 2006 20:24 I think I just realized there shouldn't be a need to actually wait for the interface to be released like I was thinking before. If there is a state variable set somewhere in the driver that records that the device has been removed and the functions of the interface fail requests based on that state, then the interface should be safe to call even after a PnP remove of the device, because whoever took out a reference to the interface will also have to have had a reference to the device object (they would have needed it to send the IRP_MN_QUERY_INTERFACE). They hopefully will continue to keep that reference while they have the interface, and it will keep the memory occupied by the device extension and the driver's code/data allocated even after a PnP remove. (and if they also had a reference to the file object then on the newer Windows the remove shouldn't even happen) So, I don't think I'm worried about IRP_MN_QUERY_INTERFACE racing with IRP_MN_QUERY_REMOVE_DEVICE anymore. Even if an interface is let out after a successful query remove then whoever has the interface should realize they can't have it any more when the remove finally does come because they should already be listening for PnP notification in order to handle the surprise removal (thanks, AG). If they aren't listening then the worst case should be the device object and/or driver take up memory for a little longer, but the system should remain stable. I guess failing a query remove is for politeness, so the race shouldn't matter. (device object references, file object references, and device interface references -- there are so many ways to reference count a single device) On Fri, 06 Oct 2006 13:35:24 -0400, BubbaGump <> wrote: >...forever...unless there's some way to notify whoever has references >to the interface to please release it? > > > > >On Fri, 06 Oct 2006 12:52:02 -0400, BubbaGump <> wrote: > >>What about the REMOVE_DEVICE that follows the SURPRISE_REMOVAL? That >>must be held forever until the interface is released, since it might >>allow the unload of the code and data to which the interface refers. >> >> >> >> >>On Fri, 6 Oct 2006 12:43:53 -0400, "Don Burn" <burn(a)stopspam.acm.org> >>wrote: >> >>>It can fail all the requests to the interface currently in progress and >>>issued in the future, it can not hold the SURPRISE_REMOVAL forever.
From: BubbaGump on 8 Oct 2006 09:42 I just noticed the description of IRP_MN_QUERY_INTERFACE also actually says to use IoRegisterPlugPlayNotification while holding the interface from another device stack, and IoRegisterPlugPlayNotification implies holding a device object reference. Things seem to fit now. On Sat, 07 Oct 2006 20:24:57 -0400, BubbaGump <> wrote: >If there is a state variable set somewhere in the driver that records >that the device has been removed and the functions of the interface >fail requests based on that state, then the interface should be safe >to call even after a PnP remove of the device, because whoever took >out a reference to the interface will also have to have had a >reference to the device object (they would have needed it to send the >IRP_MN_QUERY_INTERFACE). They hopefully will continue to keep that >reference while they have the interface, and it will keep the memory >occupied by the device extension and the driver's code/data allocated >even after a PnP remove.
From: BubbaGump on 8 Oct 2006 10:03 ....fit...except for the fact that "Handling an IRP_MN_QUERY_REMOVE_DEVICE Request" and the description of IRP_MN_QUERY_INTERFACE describe a redundant situation where both the driver holding the interface and the driver implementing the interface should deal with the interface on removal. Only one really needs too. The interface should either be released or it shouldn't and for the general case of surprise remove it should be released and from the outside before a remove, so there's no need for the query remove handler of the implementor to even care if the interface is still referenced. On Sun, 08 Oct 2006 09:42:42 -0400, BubbaGump <> wrote: >I just noticed the description of IRP_MN_QUERY_INTERFACE also actually >says to use IoRegisterPlugPlayNotification while holding the interface >from another device stack, and IoRegisterPlugPlayNotification implies >holding a device object reference. Things seem to fit now. > > > > >On Sat, 07 Oct 2006 20:24:57 -0400, BubbaGump <> wrote: > >>If there is a state variable set somewhere in the driver that records >>that the device has been removed and the functions of the interface >>fail requests based on that state, then the interface should be safe >>to call even after a PnP remove of the device, because whoever took >>out a reference to the interface will also have to have had a >>reference to the device object (they would have needed it to send the >>IRP_MN_QUERY_INTERFACE). They hopefully will continue to keep that >>reference while they have the interface, and it will keep the memory >>occupied by the device extension and the driver's code/data allocated >>even after a PnP remove.
First
|
Prev
|
Pages: 1 2 3 Prev: nonPNP sample driver won't install when running .exe Next: wdk Vista mirror driver |