All of lore.kernel.org
 help / color / mirror / Atom feed
From: Corey Minyard <cminyard@mvista.com>
To: Christian Brauner <christian.brauner@ubuntu.com>
Cc: minyard@acm.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, Adrian Reber <areber@redhat.com>,
	Oleg Nesterov <oleg@redhat.com>,
	Dmitry Safonov <0x7f454c46@gmail.com>,
	Andrei Vagin <avagin@gmail.com>
Subject: Re: [PATCH v2] pid: Fix error return value in some cases
Date: Sat, 7 Mar 2020 07:11:36 -0600	[thread overview]
Message-ID: <20200307131136.GD2847@minyard.net> (raw)
In-Reply-To: <20200307110007.fmtaaqt2udsgohtp@wittgenstein>

On Sat, Mar 07, 2020 at 12:00:07PM +0100, Christian Brauner wrote:
> On Fri, Mar 06, 2020 at 11:23:14AM -0600, minyard@acm.org wrote:
> > From: Corey Minyard <cminyard@mvista.com>
> > 
> > Recent changes to alloc_pid() allow the pid number to be specified on
> > the command line.  If set_tid_size is set, then the code scanning the
> > levels will hard-set retval to -EPERM, overriding it's previous -ENOMEM
> > value.
> > 
> > After the code scanning the levels, there are error returns that do not
> > set retval, assuming it is still set to -ENOMEM.
> > 
> > So set retval back to -ENOMEM after scanning the levels.
> > 
> > Fixes: 49cb2fc42ce4 "fork: extend clone3() to support setting a PID"
> > Signed-off-by: Corey Minyard <cminyard@mvista.com>
> > Cc: <stable@vger.kernel.org> # 5.5
> > Cc: Adrian Reber <areber@redhat.com>
> > Cc: Christian Brauner <christian.brauner@ubuntu.com>
> > Cc: Oleg Nesterov <oleg@redhat.com>
> > Cc: Dmitry Safonov <0x7f454c46@gmail.com>
> > Cc: Andrei Vagin <avagin@gmail.com>
> 
> Thanks! I've pulled the patch now and applied.
> 
> I think that restores the old behavior. If you don't mind, I'll add a
> comment on top of it saying something like:
> "ENOMEM is not the most obvious choice but it's the what we've been
>  exposing to userspace for a long time and it's also documented
>  behavior. So we can't easily change it to something more sensible."

That's great.  I was just looking through the code for another reason
and noticed the issue.  Every little thing counts for quality.

-corey

> 
> Acked-by: Christian Brauner <christian.brauner@ubuntu.com>

  reply	other threads:[~2020-03-07 13:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-06 17:23 [PATCH v2] pid: Fix error return value in some cases minyard
2020-03-07 11:00 ` Christian Brauner
2020-03-07 13:11   ` Corey Minyard [this message]
2020-03-08 17:07     ` Christian Brauner
2020-03-08 17:10     ` [PATCH] pid: make ENOMEM return value more obvious Christian Brauner
2020-03-08 17:16       ` [PATCH] selftests: add pid namespace ENOMEM regression test 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=20200307131136.GD2847@minyard.net \
    --to=cminyard@mvista.com \
    --cc=0x7f454c46@gmail.com \
    --cc=areber@redhat.com \
    --cc=avagin@gmail.com \
    --cc=christian.brauner@ubuntu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=minyard@acm.org \
    --cc=oleg@redhat.com \
    --cc=stable@vger.kernel.org \
    /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.