[PATCH 4/6] ntoskrnl.exe: Send IRP_MN_SURPRISE_REMOVAL before removing children.

[Rémi Bernon]

On 6/18/21 5:59 PM, Zebediah Figura (she/her) wrote:
> On 6/18/21 7:06 AM, Rémi Bernon wrote:
>> So that mini driver gets notified first and has a chance to cancel
>> pending IRPs.
> 
> Which minidriver?
> 
> Isn't it the responsibility of the child to terminate all pending IRPs 
> (and disallow further ones) on removal? See also [0], [1], [2], which 
> say that queued requests should be completed in (both, for some reason) 
> IRP_MN_SURPRISE_REMOVAL and IRP_MN_REMOVE_DEVICE.
> 
> I think this deserves tests.
> 
> [0] 
> https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/removing-a-device-in-a-function-driver 
> 
> 
> [1] 
> https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/handling-an-irp-mn-surprise-removal-request 
> 
> 
> [2] 
> https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/removing-a-device-in-a-bus-drive 
> 
> 

I really don't have the big picture yet, so I meant the one implemented 
in driver_hid.c. If it doesn't cancel the IRP it has queued on device 
removal, the test never completes the device removal on Windows.

On Wine, driver_hid never receives the IRP_MN_SURPRISE_REMOVAL if we 
don't call it before removing the "children" in ntoskrnl.exe. I don't 
really understand who are the children there, but driver_hid apparently 
isn't.
-- 
Rémi Bernon <rbernon at codeweavers.com>