[ovs-dev] [PATCH] datapath-windows: Solved BSOD when loading an activated extension

Sorin Vinturis svinturis at cloudbasesolutions.com
Mon Jan 26 18:39:39 UTC 2015


Nithin,

I already tried to do what you thought about, but didn't work (BSOD) because the OvsCreateDeviceObject function uses the driver handle, obtained through the NdisFRegisterFilterDriver call, to create the device object. Changing the call order of the latter functions, causes a BSOD.

Indeed, if the OvsCreateDeviceObject function fails, we must ensure that all allocated resources are released before returning the failure status, because the I/O manager won't call driver unload in this failure case.

Thanks,
Sorin

-----Original Message-----
From: Nithin Raju [mailto:nithin at vmware.com] 
Sent: Monday, 26 January, 2015 19:18
To: Sorin Vinturis
Cc: dev at openvswitch.org
Subject: Re: [ovs-dev] [PATCH] datapath-windows: Solved BSOD when loading an activated extension

> On Jan 22, 2015, at 6:12 AM, Sorin Vinturis <svinturis at cloudbasesolutions.com> wrote:
> 
> If the OVS extension was previously enabled and the driver unloaded, 
> when the driver is loaded again a BSOD is triggered.
> 
> This happens because the OVS extension registers its FilterXxx 
> routines to NDIS, by calling NdisFRegisterFilterDriver, before 
> performing all the necessary initialization. Because drivers that call 
> NdisFRegisterFilterDriver must be prepared for an immediate call to 
> any of their FilterXxx functions.
> 
> The BSOD is triggered because the FilterAttach routine, OvsExtAttach, 
> tries to acquire the control lock, when the lock is not yet initialized.
> This happens because the FilterAttach is called before the driver 
> finishes initialization, in OvsInit().

Sorin,
Thanks for the patch. This has (had) been an annoying bug.

I was wondering if it would be better to just flip the order of OvsCreateDeviceObject() and NdisFRegisterFilterDriver(). If NdisFRegisterFilterDriver() fails, it would be safe to call OvsDeleteDeviceObject().

I don’t have a strong preference, but the change would be make all of the OVS initialization code in one place rather than spread across 2 separate functions.

thanks,
-- Nithin


More information about the dev mailing list