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

[Andy Grover <agrover@redhat.com>]

On 05/11/2017 06:21 AM, Mike Snitzer wrote:
> On Thu, May 11 2017 at  5:43am -0400,
> Martin Wilck <mwilck@suse.com> wrote:
> 
>> On Thu, 2017-05-11 at 11:39 +0200, Martin Wilck wrote:
>>> On Tue, 2017-05-09 at 12:10 -0700, Andy Grover wrote:
>>>> From: Mikulas Patocka <mpatocka@redhat.com>
>>>>   
>>>> This is the very simple patch for polling on the
>>>> /dev/mapper/control
>>>> device. The select or poll function waits until any event happens
>>>> on
>>>> any
>>>> dm device since opening the /dev/mapper/control device. When select
>>>> or
>>>> poll returns the device as readable, we must close and reopen the
>>>> device
>>>> to wait for new dm events.
>>>
>>> Why have you done it that way? Couldn't you just save the
>>> dm_global_event_nr at the time poll() is called?
>>
>> I should have read your patch 2/3 before posting ... but I'm still
>> missing why the counter can't simply be set at poll() time.
> 
> If you did that then you would have a race where:
> 
> 1) userspace has recorded events prior to poll()
> 2) an event triggers an increment of dm_global_event_nr before userspace
> calls poll()
> 3) then userspace calls poll() -- only to find that after poll() returns
> multiple events have occurred.
> 
> Which implies missed handling of events.
> 
> But if I'm wrong I'm sure Andy or Mikulas will correct me.

I think getting one readiness notification for multiple events should be ok.

But, the semantics of poll(2) are level-triggered, meaning if a fd is 
ready then it will stay ready through multiple invocations of poll() 
until something is done to satisfy it (e.g. for a TCP socket, read()ing 
all the available data). Therefore we can't make it "edge-triggered" by 
auto-clearing - it has to be a separate action.

my 2c -- Regards -- Andy