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 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.