linux-kernel - Re: [BUG almost bisected] Splat in dequeue_rt

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]

Message-ID: <8094db32-5c81-4537-8809-ddfe92a0ac6c@paulmck-laptop>
Date: Wed, 28 Aug 2024 11:39:19 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Valentin Schneider <vschneid@...hat.com>
Cc: Chen Yu <yu.c.chen@...el.com>, Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org, sfr@...b.auug.org.au,
	linux-next@...r.kernel.org, kernel-team@...a.com
Subject: Re: [BUG almost bisected] Splat in dequeue_rt_stack() and build error

On Wed, Aug 28, 2024 at 08:17:06PM +0200, Valentin Schneider wrote:
> On 28/08/24 09:35, Paul E. McKenney wrote:
> > On Wed, Aug 28, 2024 at 04:32:41PM +0200, Valentin Schneider wrote:
> >> On 28/08/24 21:44, Chen Yu wrote:
> >> >
> >> > One question, although there is no DEQUEUE_DELAYED flag, it is possible
> >> > the delayed task could be dequeued from CFS tree. Because the dequeue in
> >> > set_schedule() does not have DEQUEUE_SLEEP. And in dequeue_entity():
> >> >
> >> >       bool sleep = flags & DEQUEUE_SLEEP;
> >> >
> >> >       if (flags & DEQUEUE_DELAYED) {
> >> >
> >> >       } else {
> >> >               bool delay = sleep;
> >> >               if (sched_feat(DELAY_DEQUEUE) && delay &&  //false
> >> >                  !entity_eligible(cfs_rq, se) {
> >> >               //do not dequeue
> >> >               }
> >> >       }
> >> >
> >> >       //dequeue the task    <---- we should reach here?
> >> >
> >>
> >> You're quite right, so really here the main missing bit would be the final
> >> __block_task() that a DEQUEUE_DELAYED dequeue_entities() would get us.
> >
> > 50*TREE03 passed, yay!  Thank you both!!!
> 
> Fantastic, I'll hammer this into a "proper" patch then. Thanks again for
> all the testing!
> 
> > I started a 500*TREE03.
> >
> > Yes, the odds all 50 passing given the baseline 52% failure rate is
> > something like 10^-16, but software bugs are not necessarily constrained
> > by elementary statistics...
> 
> :-)

The 500*TREE03 run had exactly one failure that was the dreaded
enqueue_dl_entity() failure, followed by RCU CPU stall warnings.

But a huge improvement over the prior state!

Plus, this failure is likely unrelated (see earlier discussions with
Peter).  I just started a 5000*TREE03 run, just in case we can now
reproduce this thing.

							Thanx, Paul