[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 6/6] Dont always remove XenFilt from UpperFilters
On 17/06/2021 13:33, Owen Smith wrote: There is a race which can prevent XenFilt from having AddDevice correctly called on some devices. This seems to happen more frequently after driver upgrades. It seems this is due to XenBus!DriverEntry removing XenFilt before XenBus!AddDevice inserts XenFilt into the UpperFilters value. In this gap, PnP manager can sample the UpperFilters key and fail to bind XenFilt to the required device stacks. This leads to XenFilt failing to determine the active device, which prevents the device unplugs from occuring, leading to a constant cycle of reboot prompts from xenbus_monitor. Signed-off-by: Owen Smith <owen.smith@xxxxxxxxxx> This is a partial reversion of 9d28a9e9b798f "Avoid removing filters on upgrade installations". I think you need to state why that commit was wrong (assuming it was). Paul --- src/xenbus/driver.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/src/xenbus/driver.c b/src/xenbus/driver.c index 1b621fa..e66bf45 100644 --- a/src/xenbus/driver.c +++ b/src/xenbus/driver.c @@ -296,6 +296,9 @@ DriverRemoveFunctionDeviceObject( RemoveEntryList(&Dx->ListEntry); ASSERT3U(Driver.References, !=, 0); References = --Driver.References; + + if (References == 1) + FiltersUninstall(); }//@@ -859,16 +862,15 @@ DriverEntry( MICRO_VERSION, BUILD_NUMBER); if (!NT_SUCCESS(status)) { - if (status == STATUS_INCOMPATIBLE_DRIVER_BLOCKED) + if (status == STATUS_INCOMPATIBLE_DRIVER_BLOCKED) { + // Re-instate XenFilt to avoid a second required reboot + FiltersInstall(); __DriverRequestReboot(); + }goto done;}- // Remove the filters from the registry. They will be re-instated by- // the first successful AddDevice. - FiltersUninstall(); - DriverObject->DriverExtension->AddDevice = DriverAddDevice;for (Index = 0; Index <= IRP_MJ_MAXIMUM_FUNCTION; Index++) {
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |