[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200903142241.GI4386@redhat.com>
Date: Thu, 3 Sep 2020 16:22:42 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Christian Brauner <christian.brauner@...ntu.com>
Cc: linux-kernel@...r.kernel.org,
Christian Brauner <christian@...uner.io>,
"Peter Zijlstra (Intel)" <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Kees Cook <keescook@...omium.org>,
Sargun Dhillon <sargun@...gun.me>,
Aleksa Sarai <cyphar@...har.com>,
linux-kselftest@...r.kernel.org,
Josh Triplett <josh@...htriplett.org>,
Jens Axboe <axboe@...nel.dk>, linux-api@...r.kernel.org,
Jann Horn <jannh@...gle.com>
Subject: Re: [PATCH v2 2/4] exit: support non-blocking pidfds
On 09/02, Christian Brauner wrote:
>
> It also makes the API more consistent and uniform. In essence, waitid() is
> treated like a read on a non-blocking pidfd or a recvmsg() on a non-blocking
> socket.
> With the addition of support for non-blocking pidfds we support the same
> functionality that sockets do. For sockets() recvmsg() supports MSG_DONTWAIT
> for pidfds waitid() supports WNOHANG.
What I personally do not like is that waitid(WNOHANG) returns zero or EAGAIN
depending on f_flags & O_NONBLOCK... This doesn't match recvmsg(MSG_DONTWAIT)
and doesn't look consistent to me.
Nevermind, the patch looks correct and if you think this can really help
user-space I won't argue.
Reviewed-by: Oleg Nesterov <oleg@...hat.com>
Powered by blists - more mailing lists