Messages in this thread | | | Date | Wed, 17 May 2023 17:26:33 +0200 | From | Oleg Nesterov <> | Subject | Re: [PATCH v9] kernel/fork: beware of __put_task_struct calling context |
| |
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 ? ;)
Oleg.
| |