Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220419160407.1740458-1-Jason@zx2c4.com> <CAG48ez3amS6=omb8XVDEz9H2bk3MxTEK_XPjD=ZO-cXcDqz-cg@mail.gmail.com>
In-Reply-To: <CAG48ez3amS6=omb8XVDEz9H2bk3MxTEK_XPjD=ZO-cXcDqz-cg@mail.gmail.com>
From:   "Jason A. Donenfeld" <Jason@zx2c4.com>
Date:   Tue, 19 Apr 2022 18:42:09 +0200
Message-ID: <CAHmME9r7Vt1XFzceHhy7O67iVMhtpLJ-d0p8UGgV4Srd4Dt2Hg@mail.gmail.com>
Subject: Re: [PATCH] random: add fork_event sysctl for polling VM forks
To:     Jann Horn <jannh@google.com>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        Alexander Graf <graf@amazon.com>,
        Dominik Brodowski <linux@dominikbrodowski.net>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "Theodore Ts'o" <tytso@mit.edu>,
        Colm MacCarthaigh <colmmacc@amazon.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hey Jann,

On Tue, Apr 19, 2022 at 6:38 PM Jann Horn <jannh@google.com> wrote:
> This is a bit of a weird API, because normally .poll is supposed to be
> level-triggered rather than edge-triggered... and AFAIK things like
> epoll also kinda assume that ->poll() doesn't modify state (but that
> only _really_ matters in weird cases). But at the same time, it looks
> like the existing proc_sys_poll() already goes against that? So I
> don't know what the right thing to do there is...

Doesn't the level vs edge distinction apply to POLLIN/POLLOUT events?
In this case, the event generated is actually POLLERR. On one hand,
this is sort of weird. On the other hand, it perhaps makes sense,
since nothing changes respect to its readability/writeability. And it
also happens to be how the sysctl poll() infrastructure was designed;
I didn't need to change anything for this behavior, and it comes as a
result of this rather trivial commit only. Looking at where else it's
used, it appears to be the intended use case for changes to
hostname/domainname. So while it's unusual, it also appears to be the
usual way that sysctl poll() works. So perhaps we're quite lucky here
in that sysctl poll() winds up being the correct interface for what we
want?

Jason