Re: [PATCH] random: add fork_event sysctl for polling VM forks

["Jason A. Donenfeld" <Jason@zx2c4.com>]

Hi Jann,

On Tue, Apr 19, 2022 at 9:45 PM Jann Horn <jannh@google.com> wrote:
> AFAIK this also means that if you make an epoll watch for
> /proc/sys/kernel/random/fork_event, and then call poll() *on the epoll
> fd* for some reason, that will probably already consume the event; and
> if you then try to actually receive the epoll event via epoll_wait(),
> it'll already be gone (because epoll tries to re-poll the "ready"
> files to figure out what state those files are at now). Similarly if
> you try to create an epoll watch for an FD that already has an event
> pending: Installing the watch will call the ->poll handler once,
> resetting the file's state, and the following epoll_wait() will call
> ->poll again and think the event is already gone. See the call paths
> to vfs_poll() in fs/eventpoll.c.
>
> Maybe we don't care about such exotic usage, and are willing to accept
> the UAPI inconsistency and slight epoll breakage of plumbing
> edge-triggered polling through APIs designed for level-triggered
> polling. IDK.

Hmm, I see. The thing is, this is _already_ what's done for
domainname/hostname. It's how the sysctl poll handler was "designed".
So our options here are:

a) Remove this quirky behavior from domainname/hostname and start
over. This would potentially break userspace, but maybe nobody uses
this? No idea, but sounds risky.

b) Apply this commit as-is, because it's using the API as the API was
designed, and call it a day.

c) Apply this commit as-is, because it's using the API as the API was
designed, and then later try to fix up the epoll behavior on this.

Of these, (a) seems like a non-starter. (c) is most appealing, but it
sounds like it might not actually be possible?

Jason