From: Oleg Nesterov <oleg@redhat.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
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 15:37:47 +0200 [thread overview]
Message-ID: <20230825133747.GA29260@redhat.com> (raw)
In-Reply-To: <87y1hzs2e4.fsf@email.froward.int.ebiederm.org>
On 08/25, Eric W. Biederman wrote:
>
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> > 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.
Yes, plus check_unsafe_exec() and zap_other_threads() which want to
skip the initial thread.
> > And kernel/bpf/task_iter.c seems to *expect* NULL at the end?
Yes. I'll (try to) send the patches today. This code needs cleanups
first.
> > 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.
Later. But so far I am not 100% sure this makes sense... I guess we
will need to discuss this again.
> Change the rest of the loops can use for_each_thread (skipping
> the current task if needed) or for_each_process_thread.
Yes, I was going to do this.
> Change next_thread to be your __next_thread, and update the 2 callers
> appropriately.
But I can't do this until I change the current users of next_thread()
and while_each_thread().
Oleg.
prev parent reply other threads:[~2023-08-25 13:40 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
2023-08-25 13:37 ` 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=20230825133747.GA29260@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--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