Thanks for the explanations guys. I think I had confused the Cancel IRP callback with the Cleanup callback. Sorry for that.
Regarding > I wouldn’t count on that that I/O on a handle and the closing of a handle > would be from the same thread context. It would look unnatural to me if the cleanup of the resources associated with the file HANDLE would be done by the OS on a a different thread (e.g. at process terminate) while code is running on the original (HANDLES's) thread, so that the OS would call Cleanup on file while process code and (an IO) is in progress. @Nithin, > Windows HANDLEs I'd think should support concurrent operations. Eg. two > userspace processes can be doing ReadFile() on the same handle. A new "open" of the device implies a new file HANDLE being created in userspace, and a new FILE_OBJECT ptr in the kernel for it. The file HANDLE / FILE_OBJECT are for the same device. So technically it should be impossible that two processes share a HANDLE. Sam ________________________________ From: Eitan Eliahu [elia...@vmware.com] Sent: Monday, September 15, 2014 6:50 PM To: Samuel Ghinet; Nithin Raju Cc: dev@openvswitch.org Subject: RE: [ovs-dev] [PATCH] datapath-windows: cleanup dump state during instance cleanup Each time that a device is opened a new file object is created with a corresponding handle. In case that a handle is duplicated in user mode there will be multiple file handles per file object associated with the handle returned by the system when the device was opened. We usually open the device per socket. I wouldn’t count on that that I/O on a handle and the closing of a handle would be from the same thread context. Thanks, Eitan From: Samuel Ghinet [mailto:sghi...@cloudbasesolutions.com] Sent: Sunday, September 14, 2014 8:04 PM To: Eitan Eliahu; Nithin Raju Cc: dev@openvswitch.org Subject: RE: [ovs-dev] [PATCH] datapath-windows: cleanup dump state during instance cleanup I have a question here, is a file HANDLE normally used by only one userspace thread at a time (so that if you have multiple threads, each thread will have its own unique file HANDLEs), or each thread may use the file HANDLEs opened by other threads? Thanks, Sam ________________________________ From: Eitan Eliahu [elia...@vmware.com] Sent: Saturday, September 13, 2014 12:01 AM To: Nithin Raju Cc: Samuel Ghinet; dev@openvswitch.org<mailto:dev@openvswitch.org> Subject: RE: [ovs-dev] [PATCH] datapath-windows: cleanup dump state during instance cleanup 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@openvswitch.org<mailto:dev@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 <elia...@vmware.com<mailto:elia...@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 _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
