All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Aleksa Sarai <cyphar@cyphar.com>
Cc: Christian Brauner <christian@brauner.io>,
	jannh@google.com, viro@zeniv.linux.org.uk,
	torvalds@linux-foundation.org, linux-kernel@vger.kernel.org,
	arnd@arndb.de, akpm@linux-foundation.org, dhowells@redhat.com,
	ebiederm@xmission.com, elena.reshetova@intel.com,
	keescook@chromium.org, luto@amacapital.net, luto@kernel.org,
	tglx@linutronix.de, linux-alpha@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org,
	linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
	sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org,
	linux-api@vger.kernel.org, linux-arch@vger.kernel.org,
	linux-kselftest@vger.kernel.org, joel@joelfernandes.orgda
Subject: Re: [PATCH v1 1/2] pid: add pidfd_open()
Date: Thu, 16 May 2019 15:22:53 +0000	[thread overview]
Message-ID: <20190516152252.GD22564@redhat.com> (raw)
In-Reply-To: <20190516151202.hrawrx7hxllmz2di@yavin>

On 05/17, Aleksa Sarai wrote:
>
> On 2019-05-16, Oleg Nesterov <oleg@redhat.com> wrote:
> > On 05/17, Aleksa Sarai wrote:
> > > On 2019-05-16, Oleg Nesterov <oleg@redhat.com> wrote:
> > > > On 05/16, Christian Brauner wrote:
> > > > > With the introduction of pidfds through CLONE_PIDFD it is possible to
> > > > > created pidfds at process creation time.
> > > >
> > > > Now I am wondering why do we need CLONE_PIDFD, you can just do
> > > >
> > > > 	pid = fork();
> > > > 	pidfd_open(pid);
> > >
> > > While the race window would be exceptionally short, there is the
> > > possibility that the child will die
> >
> > Yes,
> >
> > > and their pid will be recycled
> > > before you do pidfd_open().
> >
> > No.
> >
> > Unless the caller's sub-thread does wait() before pidfd_open(), of course.
> > Or unless you do signal(SIGCHILD, SIG_IGN).
>
> What about CLONE_PARENT?

I should have mentioned CLONE_PARENT ;)

Of course in this case the child can be reaped before pidfd_open(). But how often
do you or other people use clone(CLONE_PARENT) ? not to mention you can trivially
eliminate/detect this race if you really need this.

Don't get me wrong, I am not trying to say that CLONE_PIDFD is a bad idea.

But to me pidfd_open() is much more useful. Say, as a perl programmer I can easily
use pidfd_open(), but not CLONE_PIDFD.

Oleg.

WARNING: multiple messages have this Message-ID (diff)
From: Oleg Nesterov <oleg@redhat.com>
To: Aleksa Sarai <cyphar@cyphar.com>
Cc: Christian Brauner <christian@brauner.io>,
	jannh@google.com, viro@zeniv.linux.org.uk,
	torvalds@linux-foundation.org, linux-kernel@vger.kernel.org,
	arnd@arndb.de, akpm@linux-foundation.org, dhowells@redhat.com,
	ebiederm@xmission.com, elena.reshetova@intel.com,
	keescook@chromium.org, luto@amacapital.net, luto@kernel.org,
	tglx@linutronix.de, linux-alpha@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org,
	linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
	sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org,
	linux-api@vger.kernel.org, linux-arch@vger.kernel.org,
	linux-kselftest@vger.kernel.org, joel@joelfernandes.org,
	dancol@google.com, serge@hallyn.com,
	Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: [PATCH v1 1/2] pid: add pidfd_open()
Date: Thu, 16 May 2019 17:22:53 +0200	[thread overview]
Message-ID: <20190516152252.GD22564@redhat.com> (raw)
In-Reply-To: <20190516151202.hrawrx7hxllmz2di@yavin>

On 05/17, Aleksa Sarai wrote:
>
> On 2019-05-16, Oleg Nesterov <oleg@redhat.com> wrote:
> > On 05/17, Aleksa Sarai wrote:
> > > On 2019-05-16, Oleg Nesterov <oleg@redhat.com> wrote:
> > > > On 05/16, Christian Brauner wrote:
> > > > > With the introduction of pidfds through CLONE_PIDFD it is possible to
> > > > > created pidfds at process creation time.
> > > >
> > > > Now I am wondering why do we need CLONE_PIDFD, you can just do
> > > >
> > > > 	pid = fork();
> > > > 	pidfd_open(pid);
> > >
> > > While the race window would be exceptionally short, there is the
> > > possibility that the child will die
> >
> > Yes,
> >
> > > and their pid will be recycled
> > > before you do pidfd_open().
> >
> > No.
> >
> > Unless the caller's sub-thread does wait() before pidfd_open(), of course.
> > Or unless you do signal(SIGCHILD, SIG_IGN).
>
> What about CLONE_PARENT?

I should have mentioned CLONE_PARENT ;)

Of course in this case the child can be reaped before pidfd_open(). But how often
do you or other people use clone(CLONE_PARENT) ? not to mention you can trivially
eliminate/detect this race if you really need this.

Don't get me wrong, I am not trying to say that CLONE_PIDFD is a bad idea.

But to me pidfd_open() is much more useful. Say, as a perl programmer I can easily
use pidfd_open(), but not CLONE_PIDFD.

Oleg.


WARNING: multiple messages have this Message-ID (diff)
From: Oleg Nesterov <oleg@redhat.com>
To: Aleksa Sarai <cyphar@cyphar.com>
Cc: Christian Brauner <christian@brauner.io>,
	jannh@google.com, viro@zeniv.linux.org.uk,
	torvalds@linux-foundation.org, linux-kernel@vger.kernel.org,
	arnd@arndb.de, akpm@linux-foundation.org, dhowells@redhat.com,
	ebiederm@xmission.com, elena.reshetova@intel.com,
	keescook@chromium.org, luto@amacapital.net, luto@kernel.org,
	tglx@linutronix.de, linux-alpha@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org,
	linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
	sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org,
	linux-api@vger.kernel.org, linux-arch@vger.kernel.org,
	linux-kselftest@vger.kernel.org, joel@joelfernandes.orgda
Subject: Re: [PATCH v1 1/2] pid: add pidfd_open()
Date: Thu, 16 May 2019 17:22:53 +0200	[thread overview]
Message-ID: <20190516152252.GD22564@redhat.com> (raw)
In-Reply-To: <20190516151202.hrawrx7hxllmz2di@yavin>

On 05/17, Aleksa Sarai wrote:
>
> On 2019-05-16, Oleg Nesterov <oleg@redhat.com> wrote:
> > On 05/17, Aleksa Sarai wrote:
> > > On 2019-05-16, Oleg Nesterov <oleg@redhat.com> wrote:
> > > > On 05/16, Christian Brauner wrote:
> > > > > With the introduction of pidfds through CLONE_PIDFD it is possible to
> > > > > created pidfds at process creation time.
> > > >
> > > > Now I am wondering why do we need CLONE_PIDFD, you can just do
> > > >
> > > > 	pid = fork();
> > > > 	pidfd_open(pid);
> > >
> > > While the race window would be exceptionally short, there is the
> > > possibility that the child will die
> >
> > Yes,
> >
> > > and their pid will be recycled
> > > before you do pidfd_open().
> >
> > No.
> >
> > Unless the caller's sub-thread does wait() before pidfd_open(), of course.
> > Or unless you do signal(SIGCHILD, SIG_IGN).
>
> What about CLONE_PARENT?

I should have mentioned CLONE_PARENT ;)

Of course in this case the child can be reaped before pidfd_open(). But how often
do you or other people use clone(CLONE_PARENT) ? not to mention you can trivially
eliminate/detect this race if you really need this.

Don't get me wrong, I am not trying to say that CLONE_PIDFD is a bad idea.

But to me pidfd_open() is much more useful. Say, as a perl programmer I can easily
use pidfd_open(), but not CLONE_PIDFD.

Oleg.

WARNING: multiple messages have this Message-ID (diff)
From: oleg at redhat.com (Oleg Nesterov)
Subject: [PATCH v1 1/2] pid: add pidfd_open()
Date: Thu, 16 May 2019 17:22:53 +0200	[thread overview]
Message-ID: <20190516152252.GD22564@redhat.com> (raw)
In-Reply-To: <20190516151202.hrawrx7hxllmz2di@yavin>

On 05/17, Aleksa Sarai wrote:
>
> On 2019-05-16, Oleg Nesterov <oleg at redhat.com> wrote:
> > On 05/17, Aleksa Sarai wrote:
> > > On 2019-05-16, Oleg Nesterov <oleg at redhat.com> wrote:
> > > > On 05/16, Christian Brauner wrote:
> > > > > With the introduction of pidfds through CLONE_PIDFD it is possible to
> > > > > created pidfds at process creation time.
> > > >
> > > > Now I am wondering why do we need CLONE_PIDFD, you can just do
> > > >
> > > > 	pid = fork();
> > > > 	pidfd_open(pid);
> > >
> > > While the race window would be exceptionally short, there is the
> > > possibility that the child will die
> >
> > Yes,
> >
> > > and their pid will be recycled
> > > before you do pidfd_open().
> >
> > No.
> >
> > Unless the caller's sub-thread does wait() before pidfd_open(), of course.
> > Or unless you do signal(SIGCHILD, SIG_IGN).
>
> What about CLONE_PARENT?

I should have mentioned CLONE_PARENT ;)

Of course in this case the child can be reaped before pidfd_open(). But how often
do you or other people use clone(CLONE_PARENT) ? not to mention you can trivially
eliminate/detect this race if you really need this.

Don't get me wrong, I am not trying to say that CLONE_PIDFD is a bad idea.

But to me pidfd_open() is much more useful. Say, as a perl programmer I can easily
use pidfd_open(), but not CLONE_PIDFD.

Oleg.

WARNING: multiple messages have this Message-ID (diff)
From: oleg@redhat.com (Oleg Nesterov)
Subject: [PATCH v1 1/2] pid: add pidfd_open()
Date: Thu, 16 May 2019 17:22:53 +0200	[thread overview]
Message-ID: <20190516152252.GD22564@redhat.com> (raw)
Message-ID: <20190516152253.0Sat4ktPkRA995t2XO7G8O96AhCcgW728ffr7tk8dLI@z> (raw)
In-Reply-To: <20190516151202.hrawrx7hxllmz2di@yavin>

On 05/17, Aleksa Sarai wrote:
>
> On 2019-05-16, Oleg Nesterov <oleg@redhat.com> wrote:
> > On 05/17, Aleksa Sarai wrote:
> > > On 2019-05-16, Oleg Nesterov <oleg@redhat.com> wrote:
> > > > On 05/16, Christian Brauner wrote:
> > > > > With the introduction of pidfds through CLONE_PIDFD it is possible to
> > > > > created pidfds at process creation time.
> > > >
> > > > Now I am wondering why do we need CLONE_PIDFD, you can just do
> > > >
> > > > 	pid = fork();
> > > > 	pidfd_open(pid);
> > >
> > > While the race window would be exceptionally short, there is the
> > > possibility that the child will die
> >
> > Yes,
> >
> > > and their pid will be recycled
> > > before you do pidfd_open().
> >
> > No.
> >
> > Unless the caller's sub-thread does wait() before pidfd_open(), of course.
> > Or unless you do signal(SIGCHILD, SIG_IGN).
>
> What about CLONE_PARENT?

I should have mentioned CLONE_PARENT ;)

Of course in this case the child can be reaped before pidfd_open(). But how often
do you or other people use clone(CLONE_PARENT) ? not to mention you can trivially
eliminate/detect this race if you really need this.

Don't get me wrong, I am not trying to say that CLONE_PIDFD is a bad idea.

But to me pidfd_open() is much more useful. Say, as a perl programmer I can easily
use pidfd_open(), but not CLONE_PIDFD.

Oleg.

WARNING: multiple messages have this Message-ID (diff)
From: Oleg Nesterov <oleg@redhat.com>
To: Aleksa Sarai <cyphar@cyphar.com>
Cc: linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
	linux-mips@vger.kernel.org, dhowells@redhat.com,
	joel@joelfernandes.org, linux-kselftest@vger.kernel.org,
	sparclinux@vger.kernel.org, linux-api@vger.kernel.org,
	elena.reshetova@intel.com, linux-arch@vger.kernel.org,
	linux-s390@vger.kernel.org, dancol@google.com,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Christian Brauner <christian@brauner.io>,
	serge@hallyn.com, linux-xtensa@linux-xtensa.org,
	keescook@chromium.org, arnd@arndb.de, jannh@google.com,
	linux-m68k@lists.linux-m68k.org, viro@zeniv.linux.org.uk,
	luto@kernel.org, tglx@linutronix.de,
	linux-arm-kernel@lists.infradead.org,
	linux-parisc@vger.kernel.org, torvalds@linux-foundation.org,
	linux-kernel@vger.kernel.org, luto@amacapital.net,
	ebiederm@xmission.com, linux-alpha@vger.kernel.org,
	akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v1 1/2] pid: add pidfd_open()
Date: Thu, 16 May 2019 17:22:53 +0200	[thread overview]
Message-ID: <20190516152252.GD22564@redhat.com> (raw)
In-Reply-To: <20190516151202.hrawrx7hxllmz2di@yavin>

On 05/17, Aleksa Sarai wrote:
>
> On 2019-05-16, Oleg Nesterov <oleg@redhat.com> wrote:
> > On 05/17, Aleksa Sarai wrote:
> > > On 2019-05-16, Oleg Nesterov <oleg@redhat.com> wrote:
> > > > On 05/16, Christian Brauner wrote:
> > > > > With the introduction of pidfds through CLONE_PIDFD it is possible to
> > > > > created pidfds at process creation time.
> > > >
> > > > Now I am wondering why do we need CLONE_PIDFD, you can just do
> > > >
> > > > 	pid = fork();
> > > > 	pidfd_open(pid);
> > >
> > > While the race window would be exceptionally short, there is the
> > > possibility that the child will die
> >
> > Yes,
> >
> > > and their pid will be recycled
> > > before you do pidfd_open().
> >
> > No.
> >
> > Unless the caller's sub-thread does wait() before pidfd_open(), of course.
> > Or unless you do signal(SIGCHILD, SIG_IGN).
>
> What about CLONE_PARENT?

I should have mentioned CLONE_PARENT ;)

Of course in this case the child can be reaped before pidfd_open(). But how often
do you or other people use clone(CLONE_PARENT) ? not to mention you can trivially
eliminate/detect this race if you really need this.

Don't get me wrong, I am not trying to say that CLONE_PIDFD is a bad idea.

But to me pidfd_open() is much more useful. Say, as a perl programmer I can easily
use pidfd_open(), but not CLONE_PIDFD.

Oleg.


WARNING: multiple messages have this Message-ID (diff)
From: Oleg Nesterov <oleg@redhat.com>
To: Aleksa Sarai <cyphar@cyphar.com>
Cc: linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
	linux-mips@vger.kernel.org, dhowells@redhat.com,
	joel@joelfernandes.org, linux-kselftest@vger.kernel.org,
	sparclinux@vger.kernel.org, linux-api@vger.kernel.org,
	elena.reshetova@intel.com, linux-arch@vger.kernel.org,
	linux-s390@vger.kernel.org, dancol@google.com,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Christian Brauner <christian@brauner.io>,
	serge@hallyn.com, linux-xtensa@linux-xtensa.org,
	keescook@chromium.org, arnd@arndb.de, jannh@google.com,
	linux-m68k@lists.linux-m68k.org, viro@zeniv.linux.org.uk,
	luto@kernel.org, tglx@linutronix.de,
	linux-arm-kernel@lists.infradead.org,
	linux-parisc@vger.kernel.org, torvalds@linux-foundation.org,
	linux-kernel@vger.kernel.org, luto@amacapital.net,
	ebiederm@xmission.com, linux-alpha@vger.kernel.org,
	akpm@linux-foundation.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v1 1/2] pid: add pidfd_open()
Date: Thu, 16 May 2019 17:22:53 +0200	[thread overview]
Message-ID: <20190516152252.GD22564@redhat.com> (raw)
In-Reply-To: <20190516151202.hrawrx7hxllmz2di@yavin>

On 05/17, Aleksa Sarai wrote:
>
> On 2019-05-16, Oleg Nesterov <oleg@redhat.com> wrote:
> > On 05/17, Aleksa Sarai wrote:
> > > On 2019-05-16, Oleg Nesterov <oleg@redhat.com> wrote:
> > > > On 05/16, Christian Brauner wrote:
> > > > > With the introduction of pidfds through CLONE_PIDFD it is possible to
> > > > > created pidfds at process creation time.
> > > >
> > > > Now I am wondering why do we need CLONE_PIDFD, you can just do
> > > >
> > > > 	pid = fork();
> > > > 	pidfd_open(pid);
> > >
> > > While the race window would be exceptionally short, there is the
> > > possibility that the child will die
> >
> > Yes,
> >
> > > and their pid will be recycled
> > > before you do pidfd_open().
> >
> > No.
> >
> > Unless the caller's sub-thread does wait() before pidfd_open(), of course.
> > Or unless you do signal(SIGCHILD, SIG_IGN).
>
> What about CLONE_PARENT?

I should have mentioned CLONE_PARENT ;)

Of course in this case the child can be reaped before pidfd_open(). But how often
do you or other people use clone(CLONE_PARENT) ? not to mention you can trivially
eliminate/detect this race if you really need this.

Don't get me wrong, I am not trying to say that CLONE_PIDFD is a bad idea.

But to me pidfd_open() is much more useful. Say, as a perl programmer I can easily
use pidfd_open(), but not CLONE_PIDFD.

Oleg.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Oleg Nesterov <oleg@redhat.com>
To: Aleksa Sarai <cyphar@cyphar.com>
Cc: Christian Brauner <christian@brauner.io>,
	jannh@google.com, viro@zeniv.linux.org.uk,
	torvalds@linux-foundation.org, linux-kernel@vger.kernel.org,
	arnd@arndb.de, akpm@linux-foundation.org, dhowells@redhat.com,
	ebiederm@xmission.com, elena.reshetova@intel.com,
	keescook@chromium.org, luto@amacapital.net, luto@kernel.org,
	tglx@linutronix.de, linux-alpha@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org,
	linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
	sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org,
	linux-api@vger.kernel.org, linux-arch@vger.kernel.org,
	linux-kselftest@vger.kernel.org, joel@joelfernandes.org, da
Subject: Re: [PATCH v1 1/2] pid: add pidfd_open()
Date: Thu, 16 May 2019 17:22:53 +0200	[thread overview]
Message-ID: <20190516152252.GD22564@redhat.com> (raw)
In-Reply-To: <20190516151202.hrawrx7hxllmz2di@yavin>

On 05/17, Aleksa Sarai wrote:
>
> On 2019-05-16, Oleg Nesterov <oleg@redhat.com> wrote:
> > On 05/17, Aleksa Sarai wrote:
> > > On 2019-05-16, Oleg Nesterov <oleg@redhat.com> wrote:
> > > > On 05/16, Christian Brauner wrote:
> > > > > With the introduction of pidfds through CLONE_PIDFD it is possible to
> > > > > created pidfds at process creation time.
> > > >
> > > > Now I am wondering why do we need CLONE_PIDFD, you can just do
> > > >
> > > > 	pid = fork();
> > > > 	pidfd_open(pid);
> > >
> > > While the race window would be exceptionally short, there is the
> > > possibility that the child will die
> >
> > Yes,
> >
> > > and their pid will be recycled
> > > before you do pidfd_open().
> >
> > No.
> >
> > Unless the caller's sub-thread does wait() before pidfd_open(), of course.
> > Or unless you do signal(SIGCHILD, SIG_IGN).
>
> What about CLONE_PARENT?

I should have mentioned CLONE_PARENT ;)

Of course in this case the child can be reaped before pidfd_open(). But how often
do you or other people use clone(CLONE_PARENT) ? not to mention you can trivially
eliminate/detect this race if you really need this.

Don't get me wrong, I am not trying to say that CLONE_PIDFD is a bad idea.

But to me pidfd_open() is much more useful. Say, as a perl programmer I can easily
use pidfd_open(), but not CLONE_PIDFD.

Oleg.


  reply	other threads:[~2019-05-16 15:22 UTC|newest]

Thread overview: 95+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-16 13:59 [PATCH v1 1/2] pid: add pidfd_open() Christian Brauner
2019-05-16 13:59 ` Christian Brauner
2019-05-16 13:59 ` Christian Brauner
2019-05-16 13:59 ` Christian Brauner
2019-05-16 13:59 ` christian
2019-05-16 13:59 ` Christian Brauner
2019-05-16 13:59 ` [PATCH v1 2/2] tests: add pidfd_open() tests Christian Brauner
2019-05-16 13:59   ` Christian Brauner
2019-05-16 13:59   ` Christian Brauner
2019-05-16 13:59   ` Christian Brauner
2019-05-16 13:59   ` christian
2019-05-16 13:59   ` Christian Brauner
2019-05-16 14:27 ` [PATCH v1 1/2] pid: add pidfd_open() Oleg Nesterov
2019-05-16 14:27   ` Oleg Nesterov
2019-05-16 14:27   ` Oleg Nesterov
2019-05-16 14:27   ` Oleg Nesterov
2019-05-16 14:27   ` oleg
2019-05-16 14:27   ` Oleg Nesterov
2019-05-16 14:27   ` Oleg Nesterov
2019-05-16 14:56   ` Aleksa Sarai
2019-05-16 14:56     ` Aleksa Sarai
2019-05-16 14:56     ` Aleksa Sarai
2019-05-16 14:56     ` Aleksa Sarai
2019-05-16 14:56     ` Aleksa Sarai
2019-05-16 14:56     ` cyphar
2019-05-16 14:56     ` Aleksa Sarai
2019-05-16 14:56     ` Aleksa Sarai
2019-05-16 15:06     ` Oleg Nesterov
2019-05-16 15:06       ` Oleg Nesterov
2019-05-16 15:06       ` Oleg Nesterov
2019-05-16 15:06       ` Oleg Nesterov
2019-05-16 15:06       ` Oleg Nesterov
2019-05-16 15:06       ` oleg
2019-05-16 15:06       ` Oleg Nesterov
2019-05-16 15:06       ` Oleg Nesterov
2019-05-16 15:12       ` Aleksa Sarai
2019-05-16 15:12         ` Aleksa Sarai
2019-05-16 15:12         ` Aleksa Sarai
2019-05-16 15:12         ` Aleksa Sarai
2019-05-16 15:12         ` Aleksa Sarai
2019-05-16 15:12         ` cyphar
2019-05-16 15:12         ` Aleksa Sarai
2019-05-16 15:12         ` Aleksa Sarai
2019-05-16 15:22         ` Oleg Nesterov [this message]
2019-05-16 15:22           ` Oleg Nesterov
2019-05-16 15:22           ` Oleg Nesterov
2019-05-16 15:22           ` Oleg Nesterov
2019-05-16 15:22           ` Oleg Nesterov
2019-05-16 15:22           ` oleg
2019-05-16 15:22           ` Oleg Nesterov
2019-05-16 15:22           ` Oleg Nesterov
2019-05-16 15:29           ` Christian Brauner
2019-05-16 15:29             ` Christian Brauner
2019-05-16 15:29             ` Christian Brauner
2019-05-16 15:29             ` Christian Brauner
2019-05-16 15:29             ` christian
2019-05-16 15:29             ` Christian Brauner
2019-05-16 15:29             ` Christian Brauner
2019-05-16 14:57   ` Christian Brauner
2019-05-16 14:57     ` Christian Brauner
2019-05-16 14:57     ` Christian Brauner
2019-05-16 14:57     ` Christian Brauner
2019-05-16 14:57     ` christian
2019-05-16 14:57     ` Christian Brauner
2019-05-16 14:57     ` Christian Brauner
2019-05-16 14:56 ` Geert Uytterhoeven
2019-05-16 14:56   ` Geert Uytterhoeven
2019-05-16 14:56   ` Geert Uytterhoeven
2019-05-16 14:56   ` Geert Uytterhoeven
2019-05-16 14:56   ` Geert Uytterhoeven
2019-05-16 14:56   ` geert
2019-05-16 14:56   ` Geert Uytterhoeven
2019-05-16 14:56   ` Geert Uytterhoeven
2019-05-16 14:58   ` Christian Brauner
2019-05-16 14:58     ` Christian Brauner
2019-05-16 14:58     ` Christian Brauner
2019-05-16 14:58     ` Christian Brauner
2019-05-16 14:58     ` Christian Brauner
2019-05-16 14:58     ` christian
2019-05-16 14:58     ` Christian Brauner
2019-05-16 14:58     ` Christian Brauner
2019-05-18  9:48 ` Joel Fernandes
2019-05-18  9:48   ` Joel Fernandes
2019-05-18  9:48   ` Joel Fernandes
2019-05-18  9:48   ` Joel Fernandes
2019-05-18  9:48   ` joel
2019-05-18  9:48   ` Joel Fernandes
2019-05-18  9:48   ` Joel Fernandes
2019-05-18 10:04   ` Christian Brauner
2019-05-18 10:04     ` Christian Brauner
2019-05-18 10:04     ` Christian Brauner
2019-05-18 10:04     ` Christian Brauner
2019-05-18 10:04     ` christian
2019-05-18 10:04     ` Christian Brauner
2019-05-18 10:04     ` 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=20190516152252.GD22564@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=christian@brauner.io \
    --cc=cyphar@cyphar.com \
    --cc=dhowells@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=elena.reshetova@intel.com \
    --cc=jannh@google.com \
    --cc=joel@joelfernandes.orgda \
    --cc=keescook@chromium.org \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux-xtensa@linux-xtensa.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=sparclinux@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /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.