On Thu, 2017-05-11 at 09:21 -0400, Mike Snitzer wrote:
> On Thu, May 11 2017 at 5:43am -0400,
> Martin Wilck <mwilck@xxxxxxxx> 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@xxxxxxxxxx>
> > > >
> > > > 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.
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).
Regards
Martin
> But if I'm wrong I'm sure Andy or Mikulas will correct me.
>
> Thanks,
> Mike
>
--
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
