From: Oleg Nesterov <oleg@redhat.com>
To: Tycho Andersen <tycho@tycho.pizza>
Cc: Christian Brauner <brauner@kernel.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] pidfd: implement PIDFD_THREAD flag for pidfd_open()
Date: Wed, 31 Jan 2024 14:52:32 +0100 [thread overview]
Message-ID: <20240131135232.GA2609@redhat.com> (raw)
In-Reply-To: <ZbmwJiIS4ei64u6R@tycho.pizza>
On 01/30, Tycho Andersen wrote:
>
> On Tue, Jan 30, 2024 at 12:34:09PM +0100, Oleg Nesterov wrote:
> > Damn. Self-NACK.
> >
> > I forgot (we all ;) about mt-exec, and there are 2 problems.
> >
> > 1. The "if (!thread_group_leader(tsk))" block in de_thread() needs
> > do_notify_pidfd() too, the execing non-leader thread looses its
> > old pid, pidfd_poll(PIDFD_THREAD, pid-of-execing-sub-thread)
> > should succeed. Must be fixed, I think.
>
> I think the `test_non_tgl_exec` from my tests exercises the scenario
> you're describing, and it works.
This means your test is racy, I guess.
Look. We have a leader L, its sub-thtread T with the pid TPID, and
another process X which sleeps in pidfd_poll(PIDFD_THREAD, TPID).
T starts de_thread and kills the leader L. The leader exits and wakes
X up.
Then T does de_thread() -> exchange_tids() so we have
// BEFORE:
// pid_task(TPID, PIDTYPE_PID) == T
exchange_tids(tsk, leader);
// AFTER:
// pid_task(TPID, PIDTYPE_PID) == L
Now. If X calls pidfd_task_exited(TPID, true) "AFTER" then we are
fine, pidfd_task_exited() will return true. OK, this is not exactly
true, leader->exit_state == 0 right after exchange_tids(), but lets
ignore.
However. If X calls pidfd_task_exited(TPID, true) "BEFORE" it will
return false: pid_task(TPID) == T and T is not going to die. So
pidfd_poll() will block again forever, TPID is going to die.
See?
Fixed in v3.
> > 2. pidfd_poll(PIDFD_THREAD, pid-of-group-leader) should not succeed
> > when its sub-thread execs, the execing thread inherits the leader's
> > pid. Perhaps pidfd_task_exited() can check sig->group_exec_task,
>
> I didn't have an explicit test for this, but I hacked one up, and
> pidfd_poll(PIDFD_THREAD, pid-of-group-leader) doesn't return after
> exec.
See above, this depends on timing.
See also v3 I've sent, I tried to document the problems with mt-exec.
Oleg.
prev parent reply other threads:[~2024-01-31 13:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-30 11:26 [PATCH v2] pidfd: implement PIDFD_THREAD flag for pidfd_open() Oleg Nesterov
2024-01-30 11:34 ` Oleg Nesterov
2024-01-31 2:27 ` Tycho Andersen
2024-01-31 13:52 ` Oleg Nesterov [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=20240131135232.GA2609@redhat.com \
--to=oleg@redhat.com \
--cc=brauner@kernel.org \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tycho@tycho.pizza \
/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