On Thu, 2017-05-11 at 21:21 +0100, Alasdair G Kergon wrote: > On Thu, May 11, 2017 at 09:49:14PM +0200, Martin Wilck wrote: > > Here is an idea: the best way to avoid the race mentioned by Mike > > might > > be to set priv->global_event_nr to the highest event nr reported by > > the > > DM_LIST_DEVICES ioctl when this ioctl returns. DM_LIST_DEVICES > > would > > then represent your "separate action", which would fit quite well, > > and > > the DM_DEV_ARM_POLL ioctl wouldn't be needed. It would be > > guaranteed > > that if any event had occured after the previous DM_LIST_DEVICES, > > whether or not that had been before or after the poll() call, > > userspace > > would notice. > > > It's not really good practice to overload operations by adding and > relying upon side-effects. Yes, you could add a flag to control the > side-effect, but a separate ioctl seems to be a perfectly reasonable > approach in the present case, allowing for flexible use and not > forcing > you to generate the list when you don't need it. Except that it can cause userspace to miss events, as I tried to point out in my reply to Mike. My point is: the system call that resets the base counter should be the same system call that retrieves the events since the last reset operation. Unless I'm missing something essential, that's the only way to avoid userspace receiving events with a potentially large delay. If that system call can't be ioctl(DM_DEVICE_INFO) as you argue, it should be something else, but it should be _one_. Regards Martin -- Dr. Martin Wilck <mwilck@xxxxxxxx>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
