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:nit...@vmware.com] Sent: Monday, 26 January, 2015 19:18 To: Sorin Vinturis Cc: dev@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 > <svintu...@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 _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
