[ovs-dev] [PATCH] datapath-windows: cleanup dump state during instance cleanup

Eitan Eliahu eliahue at vmware.com
Fri Sep 12 21:01:46 UTC 2014


My understating is the Cleanup callback is called when the file handle is closed by user mode. However, at that time you can still have outstanding I/O requests in the driver or even synchronous I/O requests sent to the driver from a context of a different user mode thread. We do complete the outstanding queue IRPs but I could see a race condition here.

Do you really need to allocate memory to hold the Dump OVS message? Please note, that the memory associated with the IRP is always available until we complete the IRP. I am not sure we need to create a copy of it. If you need to hold status variables (e.g. dump index across multiple I/O dump requests) you can add them to the device instance itself. Also, it would be nice that each Dump request would be self-contained. I know it requires some user mode change (store the dump index in the socket structure).

Thanks,
Eitan

From: Nithin Raju
Sent: Friday, September 12, 2014 1:02 PM
To: Eitan Eliahu
Cc: Samuel Ghinet; dev at openvswitch.org
Subject: Re: [ovs-dev] [PATCH] datapath-windows: cleanup dump state during instance cleanup

On Sep 12, 2014, at 12:46 PM, Eitan Eliahu <eliahue at vmware.com<mailto:eliahue at vmware.com>>
 wrote:


Sorry for coming late on this one.
We should free the dump state when the system calls the driver on cleanup as you did. But, the cleanup IOCTL can be (actually will be) executed from a different thread context. This means that we need to protect  dumpState.ovsMsg.

By the time IRP_MJ_CLEANUP has been called, IRP_MJ_CLOSE has already been called. So, my understanding is that there's no scope for a userspace process to be calling into the kernel. Pls. let me know if I'm missing anything.

Thanks,
-- Nithin



More information about the dev mailing list