All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Christian Brauner <brauner@kernel.org>
Cc: Tycho Andersen <tycho@tycho.pizza>,
	linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
	Tycho Andersen <tandersen@netflix.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [PATCH v3 1/3] pidfd: allow pidfd_open() on non-thread-group leaders
Date: Fri, 26 Jan 2024 15:33:27 +0100	[thread overview]
Message-ID: <20240126143326.GC7386@redhat.com> (raw)
In-Reply-To: <20240126-lokal-aktualisieren-fef41d9bce9f@brauner>

On 01/26, Christian Brauner wrote:
>
> No, it doesn't. I'm trying to understand what you are suggesting though.
> Are you saying !task || tas->exit_state is enough

If PIDFD_THREAD then I think it is enough. Otherwise we still need
!task || (exit_state && thread_group_empty)

> and we shouldn't use
> the helper that was added in commit 38fd525a4c61 ("exit: Factor
> thread_group_exited out of pidfd_poll"). If so what does that buy us
> open-coding the check instead of using that helper? Is there an actual
> bug here?

The patch adds the new xxx_exited(task, excl) helper which checks

	!task || (exit_state && (excl || thread_group_empty))

yes, the naming is not good.

> > Well, I didn't say this is a problem. I simply do not know how/why people
> > use pidfd_poll().
>
> Sorry, I just have a hard time understanding what you wanted then. :)
>
> "I guess it is too late to change this behavior." made it sound like a)
> there's a problem and b) that you would prefer to change behavior. Thus,
> it seems that wait(WNOHANG) hanging when a traced leader of an empty
> thread-group has exited is a problem in your eyes.

Again, I mostly tried to argue with do_notify_pidfd() called by realese_task().

I think that with PIDFD_THREAD set pidfd_poll() should succeed right
after the exiting thread becomes a zombie (passes exit_notify), whether
it is a leader or not.

Let me quote part of my reply to Tycho's patch

	> +	/*
	> +	 * If we're not the leader, notify any waiters on our pidfds. Note that
	> +	 * we don't want to notify the leader until /everyone/ in the thread
	> +	 * group is dead, viz. the condition below.
	> +	 *
	> +	 * We have to do this here, since __exit_signal() will
	> +	 * __unhash_processes(), and break do_notify_pidfd()'s lookup.
	> +	 */
	> +	if (!thread_group_leader(p))
	> +		do_notify_pidfd(p);

	This doesn't look consistent.

	If the task is a group leader do_notify_pidfd() is called by exit_notify()
	when it becomes a zombie (if no other threads), before it is reaped by its
	parent (unless autoreap).

	If it is a sub-thread, it is called by release_task() above. Note that a
	sub-thread can become a zombie too if it is traced.

Not to mention that this is racy.

I would not mind if we simply move do_notify_pidfd() from exit_notify() to
release_task() and do it regardless of thread_group_leader(). And in some
sense this looks more logical to me.

But as I said:

	- I do not know how/why people actually use poll(pidfd)

	- it is too late to change the current behaviour

Sorry for confusion.

> I'm not sure whether you remember that but when we originally did the
> pidfd work you and I discussed thread support and already decided back
> then that having a flag like PIDFD_THREAD would likely be the way to go.

All I can recall is that, yes, we had some discussions about pidfd in
the past ;)

> The PIDFD_THREAD flag would be would be interesting because we could
> make pidfd_send_signal() support this flag

Agreed,

Oleg.


  reply	other threads:[~2024-01-26 14:34 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-23 15:34 [PATCH v3 0/3] pidfds for non thread group leaders Tycho Andersen
2024-01-23 15:34 ` [PATCH v3 1/3] pidfd: allow pidfd_open() on non-thread-group leaders Tycho Andersen
2024-01-23 19:56   ` Oleg Nesterov
2024-01-23 21:10     ` Tycho Andersen
2024-01-23 22:22       ` Oleg Nesterov
2024-01-24  1:25         ` Oleg Nesterov
2024-01-25 14:08       ` Oleg Nesterov
2024-01-25 17:17         ` Christian Brauner
2024-01-25 17:51           ` Oleg Nesterov
2024-01-25 18:03             ` Tycho Andersen
2024-01-25 18:25               ` Oleg Nesterov
2024-01-25 18:30                 ` Oleg Nesterov
2024-01-25 18:36                   ` Tycho Andersen
2024-01-26  9:49                     ` Christian Brauner
2024-01-26  9:42             ` Christian Brauner
2024-01-26 14:33               ` Oleg Nesterov [this message]
2024-01-26  9:47         ` Christian Brauner
2024-01-26 14:33           ` Oleg Nesterov
2024-01-27 14:26             ` Christian Brauner
2024-01-26 21:50         ` Tycho Andersen
2024-01-27 10:54           ` Oleg Nesterov
2024-01-27 14:33             ` Christian Brauner
2024-01-27 15:55             ` Tycho Andersen
2024-01-27 16:31               ` Oleg Nesterov
2024-01-27 17:20                 ` Tycho Andersen
2024-01-27 19:31                   ` Oleg Nesterov
2024-01-27 20:44                     ` Tycho Andersen
2024-01-27 21:10                       ` Oleg Nesterov
2024-01-29 11:23                         ` [RFC PATCH] pidfd: implement PIDFD_THREAD flag for pidfd_open() Oleg Nesterov
2024-01-29 13:41                           ` Christian Brauner
2024-01-29 14:31                             ` Tycho Andersen
2024-01-29 15:14                               ` Christian Brauner
2024-01-30 11:21                             ` Oleg Nesterov
2024-01-31 18:11                           ` Andy Lutomirski
2024-01-31 18:48                             ` Oleg Nesterov
2024-01-31 19:14                               ` Oleg Nesterov
2024-01-31 19:24                                 ` Andy Lutomirski
2024-01-31 19:46                                   ` Christian Brauner
2024-01-31 19:50                                     ` Andy Lutomirski
2024-02-01 13:30                                       ` Christian Brauner
2024-02-01 13:39                                         ` Christian Brauner
2024-02-01 19:33                                           ` Andy Lutomirski
2024-01-23 15:34 ` [PATCH v3 2/3] selftests/pidfd: add non-thread-group leader tests Tycho Andersen
2024-01-23 15:34 ` [PATCH v3 3/3] clone: allow CLONE_THREAD | CLONE_PIDFD together Tycho Andersen

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=20240126143326.GC7386@redhat.com \
    --to=oleg@redhat.com \
    --cc=brauner@kernel.org \
    --cc=ebiederm@xmission.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tandersen@netflix.com \
    --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 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.