[LTP] [PATCH v1 1/1] ioctl_pidfd06: expect EREMOTE for PIDFD_GET_INFO across pidns

[Petr Vorel]

Hi Jan,

> Kernel changed PIDFD_GET_INFO semantics when the pidfd refers to a task
> that has no PID in the caller's current pid namespace: return -EREMOTE
> instead of -ESRCH, allowing userspace to distinguish “different pidns”
> from “process exited”.

Good catch, thank you. This is already in Linus' tree for upcoming v7.0.

> Update ioctl_pidfd06 to expect EREMOTE in that case.

> Link: https://www.spinics.net/lists/linux-fsdevel/msg326699.html

Could you please next time use lore? Why? 1) it had some problems in the past [1]:
	lkml.org was ditched some time ago by kernel devs. It had often issues, is
	cropping messages, has no export function, has sometimes even ads on the
	site. That's why kernel.org folks run now their own reliable archive.

Therefore it was replaced in the linux kernel [2]:

	Replace the lkml.org links with lore to better use a single source
	that's more likely to stay available long-term.

Therefore:
Link: https://lore.kernel.org/linux-fsdevel/20260127225209.2293342-1-luca.boccassi@gmail.com/

The commit in upcoming v7.0 is:
ab89060fbc92e ("pidfs: return -EREMOTE when PIDFD_GET_INFO is called on another ns")
Maybe it'd be worth to use it instead of links to lore.

Also minor note about using 'Link:'. I use it the same way as kernel maintainers
- it contains a link to the patches in lore (or to patch.msgid.link which
redirect to lore): I'll add:
Link: https://lore.kernel.org/ltp/20260218190230.53759-1-japo@linux.ibm.com/

That's why I tend to use [1] for other link to not mix link to the patch with
other links.

> Link: https://lkml.org/lkml/2026/2/16/608
Also this message would be better to take from lore. But do we need a link to
the pull request itself? IMHO not.

> Link: https://lore.kernel.org/r/20260214010245.3671907-34-sashal@kernel.org
This is link is not related at all (a different commit). And it contains
[ Upstream commit 9877a865d62c9c3e0f4cc369dc9ca9f7f24f5ee9 ]
which means that this different commit is also a backport to the stable, not
patch for mainline.

> Signed-off-by: Jan Polensky <japo@linux.ibm.com>
> ---
>  testcases/kernel/syscalls/ioctl/ioctl_pidfd06.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

> diff --git a/testcases/kernel/syscalls/ioctl/ioctl_pidfd06.c b/testcases/kernel/syscalls/ioctl/ioctl_pidfd06.c
> index 751281bacb74..81205afb72a6 100644
> --- a/testcases/kernel/syscalls/ioctl/ioctl_pidfd06.c
> +++ b/testcases/kernel/syscalls/ioctl/ioctl_pidfd06.c
> @@ -41,7 +41,7 @@ static void run(void)
>  	args->exit_signal = SIGCHLD;

>  	if (!SAFE_CLONE(args)) {
> -		TST_EXP_FAIL(ioctl(pidfd, PIDFD_GET_INFO, info), ESRCH);
> +		TST_EXP_FAIL(ioctl(pidfd, PIDFD_GET_INFO, info), EREMOTE);

We are usually not that strict and accept both errnos (i.e. using
TST_EXP_FAIL_ARR()) without bothering kernel version checking if it's kind of
new feature. Sometimes it's even complicated to check the kernel version,
see a2ab37459a in bind03.c (FYI if it's required to check kernel version,
we usually detect it in the setup, e.g. 2d066ead3d).

Your approach (single errno) is used if the change is a real fix, which is
*intended* to be backported to the stable kernels (patch usually has Cc: stable
version, unlike other commits backported to stable due Fixes:). But in this case
it should use "linux-git" tag record [3].

	.tags = (const struct tst_tag[]) {
		{"linux-git", "ab89060fbc92e"},
		{}
	}

Here I'm not sure myself how severe it is. I suppose it will be backported to
stable as a fix, maybe really just add linux-git.

Kind regards,
Petr

[1] https://news.ycombinator.com/item?id=34979591
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=05a5f51ca566
[3] https://github.com/linux-test-project/ltp/blob/master/doc/old/C-Test-API.asciidoc#140-test-tags

>  		exit(0);
>  	}