[dm-devel] [PATCH 1/3] dm: a basic support for using the select or poll function

[Andy Grover]

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