[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190624095250.wtl5t5cewo7scyby@brauner.io>
Date: Mon, 24 Jun 2019 11:52:50 +0200
From: Christian Brauner <christian@...uner.io>
To: "Dmitry V. Levin" <ldv@...linux.org>
Cc: Jann Horn <jannh@...gle.com>, Oleg Nesterov <oleg@...hat.com>,
Arnd Bergmann <arnd@...db.de>, linux-api@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] samples: make pidfd-metadata fail gracefully on older
kernels
On Sun, Jun 23, 2019 at 02:32:30PM +0300, Dmitry V. Levin wrote:
> On Sat, Jun 22, 2019 at 12:13:39AM +0200, Christian Brauner wrote:
> [...]
> > Out of curiosity: what makes the new flag different than say
> > CLONE_NEWCGROUP or any new clone flag that got introduced?
> > CLONE_NEWCGROUP too would not be detectable apart from the method I gave
> > you above; same for other clone flags. Why are you so keen on being able
> > to detect this flag when other flags didn't seem to matter that much.
>
> I wasn't following uapi changes closely enough those days. ;)
(Seriously, you had one job. :) I'm joking of course.)
What you want makes sense to me overall. This way userspace can decide
easier whether to manage a process through a pidfd or needs to fallback
to a pid.
Christian
Powered by blists - more mailing lists