Messages in this thread | | | From | Valentin Schneider <> | Subject | Re: [PATCH v2 1/4] sched/task: Add the put_task_struct_atomic_safe function | Date | Mon, 30 Jan 2023 14:46:54 +0000 |
| |
On 30/01/23 08:49, Wander Lairson Costa wrote: > On Fri, Jan 27, 2023 at 12:55 PM Valentin Schneider <vschneid@redhat.com> wrote: >> >> On 23/01/23 14:24, Wander Lairson Costa wrote: >> > Therefore (if I am correct in my assumption), it would make sense for >> > only some call sites to pay the overhead price for it. But this is >> > just a guess, and I have no evidence to support my claim. >> >> My worry here is that it's easy to miss problematic callgraphs, and it's >> potentially easy for new ones to creep in. Having a solution within >> put_task_struct() itself would prevent that. >> > > We could add a WARN_ON statement in put_task_struct() to detect such cases. >
Anyone running their kernel with DEBUG_ATOMIC_SLEEP should be able to detect misuse, but it doesn't change that some callgraphs will only materialize under certain hardware/configuration combos.
>> Another thing, if you look at release_task_stack(), it either caches the >> outgoing stack for later use, or frees it via RCU (regardless of >> PREEMPT_RT). Perhaps we could follow that and just always punt the freeing >> of the task struct to RCU? >> > > That's a point. Do you mean doing that even for !PREEMPT_RT?
Could be worth a try? I think because of the cache thing the task stack is a bit less aggressive wrt RCU callback processing, but at a quick glance I don't see any fundamental reason why the task_struct itself can't be given the same treatment.
| |