Re: [PATCH 1/1] signalfd.2: Note about interactions with epoll & fork

[Andrew Clayton <andrew@digital-domain.net>]

On Mon, 23 Sep 2019 16:49:29 +0200
"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> wrote:

> Hello Andrew,

Hi Michael,

Thanks for the extensive reply!

[...]
 
> Thanks for all of the detail in the commit message! That's funky! But I
> suppose in the end it's not completely surprising, because of the fact
> that epoll is really notifying events on the open file description,
> and there may be multiple file descriptors that refer to that description
> (as for example, after fork()). It is however, still surprising to users 
> that you can read() from the FD, even though epoll doesn't say it's ready.

Ah, I gotta remember there's a distinction between descriptors &
descriptions ;) 

[...]

> Thanks for the proposed text. But I prefer to avoid mentioning 
> daemon(3), which has a longstanding bug described in its manual
> page). Also, I think we need to bring out the fact that the
> signalfd still makes signals available for reading, even though

Yes, true.

> epoll does not say the FD is ready. Also, your text might
> lead the reader to think that this sequence might be possible:
> 
> create signalfd
> create epoll instance
> add signalfd to epoll instance
> fork()
>        In child: add signalfd to epoll instance
> 
> That last step will of course give an EEXIST error from
> epoll_ctl(), because  that FD is already in the epoll
> instance.

Yup.
 
> So, I've applied your patch, but then done a fairly major rewrite,
> so that the text now looks like:
> 
>    epoll(7) semantics
>        If a process adds (via epoll_ctl(2)) a signalfd file descriptor to
>        an epoll(7) instance, then epoll_wait(2) returns events  only  for
>        signals  sent to that process.  In particular, if the process then
>        uses fork() to create a child process, then the child will be able
>        to  read(2)  signals  that  are sent to it using the signalfd file
>        descriptor, but epoll_wait(2) will not indicate that the  signalfd
>        file descriptor is ready.  In this scenario, a possible workaround
>        is that after the fork(2), the child process can  close  the  sig‐
>        nalfd  file  descriptor  that it inherited from the parent process
>        and then create another signalfd file descriptor and add it to the
>        epoll  instance.   Alternatively,  the  parent and the child could
>        delay creating their  (separate)  signalfd  file  descriptors  and
>        adding them to the epoll instance until after the call to fork(2).
> 
> Seem okay to you?

Yes, looks good.
 
> I also verified this weirness using the program shown below:

Nice example.

[...]

Cheers,
Andrew