From: Oleg Nesterov <oleg@redhat.com>
To: Davidlohr Bueso <dave@stgolabs.net>
Cc: rostedt@goodmis.org, mingo@kernel.org,
linux-kernel@vger.kernel.org, Davidlohr Bueso <dbueso@suse.de>
Subject: Re: [PATCH] fgraph: Convert ret_stack tasklist scanning to rcu
Date: Mon, 7 Sep 2020 13:43:02 +0200 [thread overview]
Message-ID: <20200907114301.GA31050@redhat.com> (raw)
In-Reply-To: <20200907013326.9870-1-dave@stgolabs.net>
On 09/06, Davidlohr Bueso wrote:
>
> Here tasklist_lock does not protect anything other than the list
> against concurrent fork/exit. And considering that the whole thing
> is capped by FTRACE_RETSTACK_ALLOC_SIZE (32), it should not be a
> problem to have a pontentially stale, yet stable, list. The task cannot
> go away either, so we don't risk racing with ftrace_graph_exit_task()
> which clears the retstack.
I don't understand this code but I think you right, tasklist_lock buys
nothing.
Afaics, with or without this change alloc_retstack_tasklist() can race
with copy_process() and miss the new child; ftrace_graph_init_task()
can't help, ftrace_graph_active can be set right after the check and
for_each_process_thread() can't see the new process yet.
This can't race with ftrace_graph_exit_task(), it is called after the
full gp pass. But this function looks very confusing to me, I don't
understand the barrier and the "NULL must become visible to IRQs before
we free it" comment.
Looks like, ftrace_graph_exit_task() was called by the exiting task
in the past? Indeed, see 65afa5e603d50 ("tracing/function-return-tracer:
free the return stack on free_task()"). I think it makes sense to
simplify this function now, it can simply do kfree(t->ret_stack) and
nothing more.
ACK, but ...
> @@ -387,8 +387,8 @@ static int alloc_retstack_tasklist(struct ftrace_ret_stack **ret_stack_list)
> }
> }
>
> - read_lock(&tasklist_lock);
then you should probably rename alloc_retstack_tasklist() ?
Oleg.
next prev parent reply other threads:[~2020-09-07 11:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-07 1:33 [PATCH] fgraph: Convert ret_stack tasklist scanning to rcu Davidlohr Bueso
2020-09-07 11:43 ` Oleg Nesterov [this message]
2020-09-18 17:12 ` Steven Rostedt
2020-09-19 11:24 ` Oleg Nesterov
2020-09-19 13:56 ` Steven Rostedt
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=20200907114301.GA31050@redhat.com \
--to=oleg@redhat.com \
--cc=dave@stgolabs.net \
--cc=dbueso@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=rostedt@goodmis.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.