linux-kernel - Re: [PATCH 0/6] sched: TTWU, IPI, and assorted stuff

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 15 Jun 2020 09:23:30 -0700
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     mingo@...nel.org, tglx@...utronix.de, linux-kernel@...r.kernel.org,
        juri.lelli@...hat.com, vincent.guittot@...aro.org,
        dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
        mgorman@...e.de, frederic@...nel.org
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