[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <xhsmh4j74o6l9.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
Date: Wed, 28 Aug 2024 20:17:06 +0200
From: Valentin Schneider <vschneid@...hat.com>
To: paulmck@...nel.org
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 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...
>
:-)
> Thanx, Paul
Powered by blists - more mailing lists