From: Yonghong Song <yonghong.song@linux.dev>
To: Oleg Nesterov <oleg@redhat.com>, Alexei Starovoitov <ast@kernel.org>
Cc: Chuyi Zhou <zhouchuyi@bytedance.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Kui-Feng Lee <kuifeng@fb.com>,
linux-kernel@vger.kernel.org, bpf@vger.kernel.org
Subject: Re: [PATCH 1/3] bpf: task_group_seq_get_next: use __next_thread() rather than next_thread()
Date: Wed, 15 Nov 2023 22:31:03 -0500 [thread overview]
Message-ID: <34440ea4-3780-45e4-9e7c-1b36b535171b@linux.dev> (raw)
In-Reply-To: <20231114163234.GA890@redhat.com>
On 11/14/23 11:32 AM, Oleg Nesterov wrote:
> Lockless use of next_thread() should be avoided, kernel/bpf/task_iter.c
> is the last user and the usage is wrong.
>
> task_group_seq_get_next() can return the group leader twice if it races
> with mt-thread exec which changes the group->leader's pid.
>
> Change the main loop to use __next_thread(), kill "next_tid == common->pid"
> check.
>
> __next_thread() can't loop forever, we can also change this code to retry
> if next_tid == 0.
>
> Signed-off-by: Oleg Nesterov <oleg@redhat.com>
> ---
> kernel/bpf/task_iter.c | 12 +++++-------
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/kernel/bpf/task_iter.c b/kernel/bpf/task_iter.c
> index 26082b97894d..51ae15e2b290 100644
> --- a/kernel/bpf/task_iter.c
> +++ b/kernel/bpf/task_iter.c
> @@ -70,15 +70,13 @@ static struct task_struct *task_group_seq_get_next(struct bpf_iter_seq_task_comm
> return NULL;
>
> retry:
> - task = next_thread(task);
> + task = __next_thread(task);
> + if (!task)
> + return NULL;
>
> next_tid = __task_pid_nr_ns(task, PIDTYPE_PID, common->ns);
> - if (!next_tid || next_tid == common->pid) {
> - /* Run out of tasks of a process. The tasks of a
> - * thread_group are linked as circular linked list.
> - */
> - return NULL;
> - }
> + if (!next_tid)
> + goto retry;
Look at the code. Looks like next_tid should never be 0 unless some
task is migrated to other namespace which I think is not possible.
common->ns is assigned as below:
common->ns = get_pid_ns(task_active_pid_ns(current))
so we are searching tasks in the *current* namespace.
Look at:
pid_t pid_nr_ns(struct pid *pid, struct pid_namespace *ns)
{
struct upid *upid;
pid_t nr = 0;
if (pid && ns->level <= pid->level) {
upid = &pid->numbers[ns->level];
if (upid->ns == ns)
nr = upid->nr;
}
return nr;
}
pid_t __task_pid_nr_ns(struct task_struct *task, enum pid_type type,
struct pid_namespace *ns)
{
pid_t nr = 0;
rcu_read_lock();
if (!ns)
ns = task_active_pid_ns(current);
nr = pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns);
rcu_read_unlock();
return nr;
}
In func pid_nr_ns(), ns->level should be equal to pid->level if pid is
in input parameter 'ns'. and in this case the return value 'nr'
should be none zero.
If this is the case, could you remove
if (!next_tid)
goto retry;
Other than above, the change looks good to me.
>
> if (skip_if_dup_files && task->files == task->group_leader->files)
> goto retry;
next prev parent reply other threads:[~2023-11-16 3:31 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-14 16:32 [PATCH 0/3] bpf: kernel/bpf/task_iter.c: don't abuse next_thread() Oleg Nesterov
2023-11-14 16:32 ` [PATCH 1/3] bpf: task_group_seq_get_next: use __next_thread() rather than next_thread() Oleg Nesterov
2023-11-16 3:31 ` Yonghong Song [this message]
2023-11-16 9:34 ` Oleg Nesterov
2023-11-16 11:46 ` Yonghong Song
2023-11-14 16:32 ` [PATCH 2/3] bpf: bpf_iter_task_next: " Oleg Nesterov
2023-11-16 3:34 ` Yonghong Song
2023-11-14 16:32 ` [PATCH 3/3] bpf: bpf_iter_task_next: use next_task(kit->task) rather than next_task(kit->pos) Oleg Nesterov
2023-11-16 5:16 ` Yonghong Song
2023-11-16 9:38 ` Oleg Nesterov
2023-11-16 3:13 ` [PATCH 0/3] bpf: kernel/bpf/task_iter.c: don't abuse next_thread() Yonghong Song
2023-11-16 9:54 ` Oleg Nesterov
2023-11-16 11:52 ` Yonghong Song
2023-11-19 20:00 ` patchwork-bot+netdevbpf
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=34440ea4-3780-45e4-9e7c-1b36b535171b@linux.dev \
--to=yonghong.song@linux.dev \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kuifeng@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=zhouchuyi@bytedance.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox