[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20251106105401.220218-1-sieberf@amazon.com>
Date: Thu, 6 Nov 2025 12:54:01 +0200
From: Fernand Sieber <sieberf@...zon.com>
To: <peterz@...radead.org>
CC: <aubrey.li@...ux.intel.com>, <jstultz@...gle.com>,
<linux-kernel@...r.kernel.org>, <lkp@...el.com>, <oe-lkp@...ts.linux.dev>,
<oliver.sang@...el.com>, <sieberf@...zon.com>, <x86@...nel.org>,
<yu.c.chen@...el.com>
Subject: Re: [tip:sched/core] [sched/fair] 79104becf4: BUG:kernel_NULL_pointer_dereference,address
Hi Peter,
> 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
Amazon Development Centre (South Africa) (Proprietary) Limited
29 Gogosoa Street, Observatory, Cape Town, Western Cape, 7925, South Africa
Registration Number: 2004 / 034463 / 07
Powered by blists - more mailing lists