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