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

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

[Jan Polensky]

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”.

Update ioctl_pidfd06 to expect EREMOTE in that case.

Link: https://www.spinics.net/lists/linux-fsdevel/msg326699.html
Link: https://lkml.org/lkml/2026/2/16/608
Link: https://lore.kernel.org/r/20260214010245.3671907-34-sashal@kernel.org
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);
 		exit(0);
 	}
 
-- 
2.53.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [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);
>  	}

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Andrea Cervesato via ltp]

Hi!

> 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).
>

This is a tricky situation where we might use both approaches.
TST_EXP_FAIL_ARR() would be my first go, but it's also true that the
syscall should not fail with EREMOTE for un-patched kernels. We should
expect that kernel fails with ESRCH. And we don't want to hide bugs.

Anyway..

We also don't have ways to verify if the underlying kernel has been
patched or not, so we should assume that any kernel might receive this
backported patch and TST_EXP_FAIL_ARR() remains the only logical
solution for this test.

> 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);
> >  	}

Also, since this is a new feature which has not been merged yet,
we should tag the patch with [STAGING] tag in the git commit subject as
per:

https://linux-test-project.readthedocs.io/en/latest/developers/ground_rules.html#kernel-features-and-rcs

-- 
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

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

[Jan Polensky]

On Thu, Feb 19, 2026 at 09:49:20AM +0100, Andrea Cervesato wrote:

>
> This is a tricky situation where we might use both approaches.
> TST_EXP_FAIL_ARR() would be my first go, but it's also true that the
> syscall should not fail with EREMOTE for un-patched kernels. We should
> expect that kernel fails with ESRCH. And we don't want to hide bugs.
>
> Anyway..
>
> We also don't have ways to verify if the underlying kernel has been
> patched or not, so we should assume that any kernel might receive this
> backported patch and TST_EXP_FAIL_ARR() remains the only logical
> solution for this test.
>
[snip]
>
> Also, since this is a new feature which has not been merged yet,
> we should tag the patch with [STAGING] tag in the git commit subject as
> per:
>
> https://linux-test-project.readthedocs.io/en/latest/developers/ground_rules.html#kernel-features-and-rcs
>
> --
> Andrea Cervesato
> SUSE QE Automation Engineer Linux
> andrea.cervesato@suse.com
>
Hi Petr,
thank you very much for your detailed feedback. Your notes helped improve
my understanding, and I really appreciate the time and effort you put
into the review.

Hi Andrea,
thanks a lot for your suggestions as well.

I followed your suggestions as closely as possible and will send a v2
next.

Best regards,
Jan


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp