linux-man.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Richard Palethorpe <rpalethorpe@suse.de>
To: Jakub Wilk <jwilk@jwilk.net>
Cc: linux-man@vger.kernel.org,
	Alejandro Colomar <alx.manpages@gmail.com>,
	Michael Kerrisk <mtk.manpages@gmail.com>
Subject: Re: [PATCH] wait.2: Add ESRCH for when pid == INT_MIN
Date: Tue, 13 Jul 2021 08:37:42 +0100	[thread overview]
Message-ID: <871r827jg9.fsf@suse.de> (raw)
In-Reply-To: <20210712161159.no5qnjjzsrjev2s3@jwilk.net>

Hello Jakub,

Jakub Wilk <jwilk@jwilk.net> writes:

> * Richard Palethorpe <rpalethorpe@suse.com>, 2021-07-08, 11:08:
>>Please see upstream commit:
>>
>> commit dd83c161fbcc5d8be637ab159c0de015cbff5ba4
>> Author: zhongjiang <zhongjiang@huawei.com>
>> Date:   Mon Jul 10 15:53:01 2017 -0700
>>
>>     kernel/exit.c: avoid undefined behaviour when calling wait4()
>>
>>It avoids negating INT_MIN by returning early with ESRCH.
>
> That sounds like a bug in the kernel, though?
>
> POSIX says the error should be ECHILD if "the process group specified
> by pid does not exist".

The absolute value of INT_MIN is undefined or "not representable" in
two's complement. So I think this can reasonably be considered undefined
behaviour and the kernel can do what it wants.

Also, as the error code is different, we can detect if the fix has been
applied without UBSAN enabled (unlike a similar fix in kill).

OTOH, I would have probably used ECHILD for consistency. However it is
done now and has been in use for some years.

-- 
Thank you,
Richard.

      reply	other threads:[~2021-07-13  7:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-08 10:08 [PATCH] wait.2: Add ESRCH for when pid == INT_MIN Richard Palethorpe
2021-07-10 18:15 ` Alejandro Colomar (man-pages)
2021-07-12 16:11 ` Jakub Wilk
2021-07-13  7:37   ` Richard Palethorpe [this message]

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=871r827jg9.fsf@suse.de \
    --to=rpalethorpe@suse.de \
    --cc=alx.manpages@gmail.com \
    --cc=jwilk@jwilk.net \
    --cc=linux-man@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).