From: "Rémi Bernon" Subject: Re: [PATCH 4/6] ntoskrnl.exe: Send IRP_MN_SURPRISE_REMOVAL before removing children. Message-Id: <271c8c1f-ff25-5eaa-cb94-f4c42f7582f3@codeweavers.com> Date: Fri, 18 Jun 2021 20:49:24 +0200 In-Reply-To: References: <20210618120611.703993-1-rbernon@codeweavers.com> <20210618120611.703993-4-rbernon@codeweavers.com> 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