From: ebiederm@xmission.com (Eric W. Biederman)
To: Jim Newsome <jnewsome@torproject.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Oleg Nesterov <oleg@redhat.com>,
Christian Brauner <christian@brauner.io>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] do_wait: make PIDTYPE_PID case O(1) instead of O(n)
Date: Thu, 11 Mar 2021 10:30:08 -0600 [thread overview]
Message-ID: <m1lfatlkkv.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <4d9006b4-b65a-6ce0-b367-971f29de1f21@torproject.org> (Jim Newsome's message of "Wed, 10 Mar 2021 18:14:44 -0600")
Jim Newsome <jnewsome@torproject.org> writes:
> On 3/10/21 16:40, Eric W. Biederman wrote:
>>> +// Optimization for waiting on PIDTYPE_PID. No need to iterate
> through child
>>> +// and tracee lists to find the target task.
>>
>> Minor nit: C++ style comments look very out of place in this file
>> which uses old school C /* */ comment delimiters for
>> all of it's block comments.
>
> Will do
>
>>> +static int do_wait_pid(struct wait_opts *wo)
>>> +{
>>> + struct task_struct *target = pid_task(wo->wo_pid, PIDTYPE_PID);
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> This is subtle change in behavior.
>>
>> Today on the task->children list we only place thread group leaders.
>
> Shouldn't we allow waiting on clone children if __WALL or __WCLONE is set?
>
> This is already checked later in `eligible_child`, called from
> `wait_consider_task`, so I *think* the current form should already do
> the right thing. Now I'm confused though how the general path (through
> `do_wait_thread`) works if clone children aren't on the task->children
> list...?
>
> (In any case it seems this will need another version with at least an
> explanatory comment here)
What I am worried about are not clone children. AKA ordinary children
that have a different exit signal but CLONE_THREAD children that are
never put on the children list so are naturally excluded from today's
do_wait (except in the case of ptrace). These are also known as threads.
Maybe I am missing it but I don't see anything in wait_consider_task
or in the way that you are calling it that would exclude CLONE_THREAD
children for the non-ptrace case.
Eric
next prev parent reply other threads:[~2021-03-11 16:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-09 20:39 [PATCH v3] do_wait: make PIDTYPE_PID case O(1) instead of O(n) Jim Newsome
2021-03-10 17:27 ` Oleg Nesterov
2021-03-10 22:40 ` Eric W. Biederman
2021-03-11 0:14 ` Jim Newsome
2021-03-11 15:15 ` Oleg Nesterov
2021-03-11 16:26 ` Jim Newsome
2021-03-11 16:30 ` Eric W. Biederman [this message]
2021-03-11 15:08 ` Oleg Nesterov
2021-03-11 16:37 ` Eric W. Biederman
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=m1lfatlkkv.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=christian@brauner.io \
--cc=jnewsome@torproject.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
/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.