On 05/11/2017 12:30 PM, Martin Wilck wrote:
I see - but I don't see yet how the ioctl approach (or the
close()/open() based one, for that matter) would avoid this race.
1) application processes event N
2) event N+1 arrives in the kernel
3) user space issues ioctl or close()/open() sequence, N+1 is recorded
in priv->global_event_nr
4) user space runs poll()
5) event N+2 arrives 4 weeks later and poll returns
... meaning that event N+1 has been left unprocessed for 4 weeks.
Or what I am missing?
AFAICS, the only way for user space to make sure it misses no events
would be passing the number of the last processed event down the kernel
in the ioctl call (and the kernel would use that value, rather than its
internal counter, for initializing priv->global_event_nr).
a) Application notes initial event_nrs for all relevant devices
while (1)
b) Application calls ARM_POLL
c) Application gets updated event_nrs from LIST_DEVICES and handles
d) Application calls poll()
If events arrive between b and c, app sees them.
If events arrive between c and d, dm_global_event_nr is greater than
priv->global_event_nr and poll() will indicate fd is ready immediately
w/o sleeping.
If events arrive after d, app sleeps in poll() until fd is ready.
The difference is that you have to ARM_POLL and *then* process events
before calling poll(). The only small negative consequence is that if an
event arrives between b and c, it will be handled by c but poll() will
still see readiness and pop out of the poll() and loop again when it
strictly didn't have to. But events won't be lost.
Regards -- Andy
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
