Messages in this thread | | | From | Wander Lairson Costa <> | Date | Wed, 17 May 2023 13:57:09 -0300 | Subject | Re: [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. >
| |