From: Cyril Hrubis <chrubis@suse.cz>
To: Andrea Cervesato <andrea.cervesato@suse.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH 5/6] Add ioctl_pidfd03 test
Date: Mon, 30 Jun 2025 16:30:18 +0200 [thread overview]
Message-ID: <aGKferpgXPDQ5fSt@yuki.lan> (raw)
In-Reply-To: <df64c1e1-79bb-4fb8-8360-cc9d0e85e774@suse.com>
Hi!
> > If I'm reading the kernel code correctly, we should get the same result
> > even before the pid was waited for, so we may as well do this check
> > twice, once before the WAITPID() and once after the WAITPID().
> In this case, ESRCH is obtained only when info->mask == 0 __after__
> child has been reaped.
> If child has not completed, we obtain the same result of the
> ioctl_pidfd02 check before waitpid().
Sigh, right, I misread the kernel code again.
We get ESRCH in the case of:
- the target pid is not in our namespace or child namespace
- task was reaped and PIDFD_INFO_EXIT was not set
- task was reaped before we called get_task_cred()
- task was reaped after we filled in data from task_cred
(there is another check at the end of the function to make sure we do
not return stale data)
So I suppose that we can hit the first two, the second two are
inherently racy.
So after all with a pidfd pointing to a process in a child pid namespace
we get all the uids/gids and pid filled in. Possibly changed by
mappings, but I suppose these are going to be 1:1 since we haven't set
any mapping tables.
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2025-06-30 14:29 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-26 12:34 [LTP] [PATCH 0/6] ioctl_pidfd testing suite Andrea Cervesato
2025-06-26 12:34 ` [LTP] [PATCH 1/6] Provide pidfd parameter in tst_clone_args Andrea Cervesato
2025-06-26 12:34 ` [LTP] [PATCH 2/6] Fallback PIDFD_GET_INFO related definitions Andrea Cervesato
2025-06-26 12:34 ` [LTP] [PATCH 3/6] Add ioctl_pidfd01 test Andrea Cervesato
2025-06-26 12:34 ` [LTP] [PATCH 4/6] Add ioctl_pidfd02 test Andrea Cervesato
2025-06-27 9:11 ` Cyril Hrubis
2025-06-27 9:47 ` Cyril Hrubis
2025-06-27 9:53 ` Cyril Hrubis
2025-06-26 12:34 ` [LTP] [PATCH 5/6] Add ioctl_pidfd03 test Andrea Cervesato
2025-06-27 9:56 ` Cyril Hrubis
2025-06-30 12:50 ` Andrea Cervesato via ltp
2025-06-30 14:30 ` Cyril Hrubis [this message]
2025-06-26 12:34 ` [LTP] [PATCH 6/6] Add ioctl_pidfd04 test Andrea Cervesato
2025-06-27 10:14 ` [LTP] [PATCH 0/6] ioctl_pidfd testing suite Cyril Hrubis
2025-07-01 11:15 ` Andrea Cervesato via ltp
2025-07-01 11:40 ` Cyril Hrubis
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=aGKferpgXPDQ5fSt@yuki.lan \
--to=chrubis@suse.cz \
--cc=andrea.cervesato@suse.com \
--cc=ltp@lists.linux.it \
/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.