From: Oleg Nesterov <oleg@redhat.com>
To: Christian Brauner <christian.brauner@ubuntu.com>
Cc: linux-kernel@vger.kernel.org,
Christian Brauner <christian@brauner.io>,
"Peter Zijlstra (Intel)" <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Kees Cook <keescook@chromium.org>,
Sargun Dhillon <sargun@sargun.me>,
Aleksa Sarai <cyphar@cyphar.com>,
linux-kselftest@vger.kernel.org,
Josh Triplett <josh@joshtriplett.org>,
Jens Axboe <axboe@kernel.dk>,
linux-api@vger.kernel.org
Subject: Re: [PATCH 1/4] pidfd: support PIDFD_NONBLOCK in pidfd_open()
Date: Tue, 1 Sep 2020 18:53:16 +0200 [thread overview]
Message-ID: <20200901165315.GD4386@redhat.com> (raw)
In-Reply-To: <20200901163308.mwd334y462fmml6s@wittgenstein>
On 09/01, Christian Brauner wrote:
>
> On Tue, Sep 01, 2020 at 06:23:10PM +0200, Oleg Nesterov wrote:
> > On 08/31, Christian Brauner wrote:
> > >
> > > --- /dev/null
> > > +++ b/include/uapi/linux/pidfd.h
> > > @@ -0,0 +1,12 @@
> > > +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> > > +
> > > +#ifndef _UAPI_LINUX_PIDFD_H
> > > +#define _UAPI_LINUX_PIDFD_H
> > > +
> > > +#include <linux/types.h>
> > > +#include <linux/fcntl.h>
> > > +
> > > +/* Flags for pidfd_open(). */
> > > +#define PIDFD_NONBLOCK O_NONBLOCK
> > > +
> > > +#endif /* _UAPI_LINUX_PIDFD_H */
> >
> > Why? Can't we simply use O_NONBLOCK ?
>
> It's the same thing we seem to do for any other (anon inode) fds:
>
> include/linux/eventfd.h:#define EFD_NONBLOCK O_NONBLOCK
> include/uapi/linux/inotify.h:#define IN_NONBLOCK O_NONBLOCK
> include/uapi/linux/signalfd.h:#define SFD_NONBLOCK O_NONBLOCK
> include/uapi/linux/timerfd.h:#define TFD_NONBLOCK O_NONBLOCK
>
> also for O_CLOEXEC:
>
> include/linux/eventfd.h:#define EFD_CLOEXEC O_CLOEXEC
> include/linux/userfaultfd_k.h:#define UFFD_CLOEXEC O_CLOEXEC
> include/uapi/linux/eventpoll.h:#define EPOLL_CLOEXEC O_CLOEXEC
> include/uapi/linux/mount.h:#define OPEN_TREE_CLOEXEC O_CLOEXEC
> include/uapi/linux/perf_event.h:#define PERF_FLAG_FD_CLOEXEC (1UL << 3) /* O_CLOEXEC */
> include/uapi/linux/signalfd.h:#define SFD_CLOEXEC O_CLOEXEC
> include/uapi/linux/timerfd.h:#define TFD_CLOEXEC O_CLOEXEC
>
> So I think we should just do the same.
Hmm, OK, then I have to agree.
> A clean flag namespace seems
> nicer to me too tbh.
Disagree but this doesn't matter ;)
Oleg.
next prev parent reply other threads:[~2020-09-01 16:53 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-31 13:45 [PATCH 0/4] Support non-blocking pidfds Christian Brauner
2020-08-31 13:45 ` [PATCH 1/4] pidfd: support PIDFD_NONBLOCK in pidfd_open() Christian Brauner
2020-09-01 16:23 ` Oleg Nesterov
2020-09-01 16:33 ` Christian Brauner
2020-09-01 16:53 ` Oleg Nesterov [this message]
2020-08-31 13:45 ` [PATCH 2/4] exit: support non-blocking pidfds Christian Brauner
2020-09-01 16:11 ` Oleg Nesterov
2020-09-01 16:18 ` Christian Brauner
2020-08-31 13:45 ` [PATCH 3/4] tests: port pidfd_wait to kselftest harness Christian Brauner
2020-08-31 13:45 ` [PATCH 4/4] tests: add waitid() tests for non-blocking pidfds Christian Brauner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200901165315.GD4386@redhat.com \
--to=oleg@redhat.com \
--cc=axboe@kernel.dk \
--cc=christian.brauner@ubuntu.com \
--cc=christian@brauner.io \
--cc=cyphar@cyphar.com \
--cc=ebiederm@xmission.com \
--cc=josh@joshtriplett.org \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=sargun@sargun.me \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.