Messages in this thread | | | Date | Mon, 15 Jun 2020 09:23:30 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH 0/6] sched: TTWU, IPI, and assorted stuff |
| |
On Mon, Jun 15, 2020 at 02:56:54PM +0200, Peter Zijlstra wrote: > Hi, > > So Paul reported rcutorture hitting a NULL dereference, and patch #1 fixes it. > > Now, patch #1 is obviously correct, but I can't explain how exactly it leads to > the observed NULL pointer dereference. The NULL pointer deref happens in > find_matching_se()'s last while() loop when is_same_group() fails even though > both parents are NULL.
My bisection of yet another bug sometimes hits the scheduler NULL pointer dereference on older commits. I will try out patch #2.
Whether this is reassuring or depressing, I have no idea. :-/
> The only explanation I have for that is that we just did an activate_task() > while: 'task_cpu(p) != cpu_of(rq)', because then 'p->se.cfs_rq' doesn't match. > However, I can't see how the lack of #1 would lead to that. Never-the-less, > patch #2 adds assertions to warn us of this case. > > Patch #3 is a trivial rename that ought to eradicate some confusion. > > The last 3 patches is what I ended up with for cleaning up the whole > smp_call_function/irq_work/ttwu thing more.
Would it be possible to allow a target CPU # on those instances of __call_single_data? This is extremely helpful for debugging lost smp_call_function*() calls.
Thanx, Paul
| |