lkml.org 
[lkml]   [2023]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v9] kernel/fork: beware of __put_task_struct calling context
On Wed, May 17, 2023 at 12:26 PM Oleg Nesterov <oleg@redhat.com> wrote:
>
> On 05/16, Wander Lairson Costa wrote:
> >
> > static inline void put_task_struct(struct task_struct *t)
> > {
> > - if (refcount_dec_and_test(&t->usage))
> > + if (!refcount_dec_and_test(&t->usage))
> > + return;
> > +
> > + /*
> > + * under PREEMPT_RT, we can't call put_task_struct
> > + * in atomic context because it will indirectly
> > + * acquire sleeping locks.
> > + *
> > + * call_rcu() will schedule delayed_put_task_struct_rcu()
> > + * to be called in process context.
> > + *
> > + * __put_task_struct() is called when
> > + * refcount_dec_and_test(&t->usage) succeeds.
> > + *
> > + * This means that it can't "conflict" with
> > + * put_task_struct_rcu_user() which abuses ->rcu the same
> > + * way; rcu_users has a reference so task->usage can't be
> > + * zero after rcu_users 1 -> 0 transition.
> > + *
> > + * delayed_free_task() also uses ->rcu, but it is only called
> > + * when it fails to fork a process. Therefore, there is no
> > + * way it can conflict with put_task_struct().
> > + */
> > + if (IS_ENABLED(CONFIG_PREEMPT_RT) && !preemptible())
> > + call_rcu(&t->rcu, __put_task_struct_rcu_cb);
> > + else
> > __put_task_struct(t);
> > }
>
> LGTM but we still need to understand the possible problems with CONFIG_PROVE_RAW_LOCK_NESTING ...
>
> Again, I'll try to investigate when I have time although I am not sure I can really help.
>
> Perhaps you too can try to do this ? ;)
>

FWIW, I tested this patch with CONFIG_PROVE_LOCK_NESTING in RT and
stock kernels. No splat happened.

> Oleg.
>

\
 
 \ /
  Last update: 2023-05-17 18:58    [W:0.165 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site