From: "Eric W. Biederman" <ebiederm@xmission.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
peterz@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] introduce __next_thread(), change next_thread()
Date: Fri, 25 Aug 2023 08:00:19 -0500 [thread overview]
Message-ID: <87y1hzs2e4.fsf@email.froward.int.ebiederm.org> (raw)
In-Reply-To: <CAHk-=whB2Cnmr2u8g5h57i8JfUoS3Qe=Pz7Bd8or3=ndJnQaWw@mail.gmail.com> (Linus Torvalds's message of "Thu, 24 Aug 2023 08:02:51 -0700")
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, 24 Aug 2023 at 07:32, Oleg Nesterov <oleg@redhat.com> wrote:
>>
>> After document-while_each_thread-change-first_tid-to-use-for_each_thread.patch
>> in mm tree + this series
>
> Looking at your patch 2/2, I started looking at users ("Maybe we
> *want* NULL for the end case, and make next_thread() and __next_thread
> be the same?").
>
> One of the main users is while_each_thread(), which certainly wants
> that NULL case, both for an easier loop condition, but also because
> the only user that uses the 't' pointer after the loop is
> fs/proc/base.c, which wants it to be NULL.
Sort of.
I have found 3 loops that want to loop through all of the threads of
a process starting with the current thread.
The loop in do_wait.
The loop finding the thread to signal in complete_signal.
The loop in retarget_shared_pending finding which threads
to wake up.
For the signal case that is just quality of implementation,
and starting somewhere else would just decrease that quality.
For the loop in do_wait it is a correctness issue that the code
starts first with the threads own children before looking for
children of other threads.
There are 4 users of next_thread outside of while_each_thread.
- next_tid -- wants NULL
- task_group_seq_get_next -- same as next_tid
- __exit_signal -- wants any thread on the list after __unhash_process
- complete_signal -- wants the same loop as do_wait.
> And kernel/bpf/task_iter.c seems to *expect* NULL at the end?
>
> End result: if you're changing next_thread() anyway, please just
> change it to be a completely new thing that returns NULL at the end,
> which is what everybody really seems to want, and don't add a new
> __next_thread() helper. Ok?
So I would say Oleg please build the helper that do_wait wants
and use it in do_wait, complete_signal, and retarget_shared_pending.
Change the rest of the loops can use for_each_thread (skipping
the current task if needed) or for_each_process_thread.
Change __exit_signal to use signal->group_leader instead of next_thread.
Change next_thread to be your __next_thread, and update the 2 callers
appropriately.
Eric
next prev parent reply other threads:[~2023-08-25 13:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-24 14:31 [PATCH 0/2] introduce __next_thread(), change next_thread() Oleg Nesterov
2023-08-24 14:31 ` [PATCH 1/2] introduce __next_thread(), fix next_tid() vs exec() race Oleg Nesterov
2023-08-24 14:32 ` [PATCH 2/2] change next_thread() to use __next_thread() ?: group_leader Oleg Nesterov
2023-08-24 14:40 ` [PATCH 0/2] introduce __next_thread(), change next_thread() Oleg Nesterov
2023-08-24 15:02 ` Linus Torvalds
2023-08-24 15:47 ` Oleg Nesterov
2023-08-24 15:53 ` Oleg Nesterov
2023-08-25 13:00 ` Eric W. Biederman [this message]
2023-08-25 13:37 ` Oleg Nesterov
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=87y1hzs2e4.fsf@email.froward.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=peterz@redhat.com \
--cc=torvalds@linux-foundation.org \
/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