[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANDhNCpZWFsxZsmbXY2Q6DBfovqas8haepdYyx=RpWsZGDKN0A@mail.gmail.com>
Date: Thu, 6 Nov 2025 15:57:03 -0800
From: John Stultz <jstultz@...gle.com>
To: Fernand Sieber <sieberf@...zon.com>
Cc: peterz@...radead.org, aubrey.li@...ux.intel.com,
linux-kernel@...r.kernel.org, lkp@...el.com, oe-lkp@...ts.linux.dev,
oliver.sang@...el.com, x86@...nel.org, yu.c.chen@...el.com
Subject: Re: [tip:sched/core] [sched/fair] 79104becf4: BUG:kernel_NULL_pointer_dereference,address
On Thu, Nov 6, 2025 at 2:54 AM Fernand Sieber <sieberf@...zon.com> wrote:
> > But yeah, if the task holding your resource is doing yield() you're
> > 'sad'. Basically a sched-fair yield() means: I've no fucking clue what
> > I'm doing and lets hope we can make progress a little later.
> >
> > And it gets worse in the context of PI/proxy, because in that case your
> > fair task can deadlock the system through sheer incompetence.
> >
> > Anyway, consider the PI case, we bump a fair task to FIFO and then
> > yield() would do the FIFO yield -- with all the possible problems.
> >
> > And we want the same for proxy, if the boosting context is FIFO, we want
> > a FIFO yield.
>
> Alright, makes sense. Based on your suggestion I've submitted a patch:
> lore.kernel.org/lkml/20251106104022.195157-1-sieberf@...zon.com/T/#u
>
> This is essentially the same as your suggestion + handling of yield to and
> scx.
>
> Also confirmed no crashes with this patch + v3 of the vruntime forfeit patch
> https://lore.kernel.org/lkml/20250918150528.292620-1-sieberf@amazon.com/
>
Fernand, Thank you so much for root causing this, and helping validate
the fix works!
I apologise for missing this case in my testing. I'll try to see if I
can include the trinity test in my regular stress testing.
Do let me know if you do see any other proxy related issues!
thanks
-john
Powered by blists - more mailing lists