On Sat, 19 Sep 2020 13:24:39 +0200
Oleg Nesterov wrote:
> On 09/18, Steven Rostedt wrote:
> >
> > On Mon, 7 Sep 2020 13:43:02 +0200
> > Oleg Nesterov wrote:
> >
> > > Afaics, with or without this change alloc_retstack_tasklist() can race
> > > with copy_process() and miss the new child;
On 09/18, Steven Rostedt wrote:
>
> On Mon, 7 Sep 2020 13:43:02 +0200
> Oleg Nesterov wrote:
>
> > 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
[ Back from my PTO and still digging out emails ]
On Mon, 7 Sep 2020 13:43:02 +0200
Oleg Nesterov wrote:
> 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
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.
It seems that alloc_retstack_tasklist() can also take a lockless
approach for scanning the tasklist, instead of using the big global
tasklist_lock. For this we also kill another deprecated and rcu-unsafe
tsk->thread_group user replacing it with for_each_process_thread(),
maintaining semantics.
5 matches
Mail list logo