From: Hao Jia <jiahao.kernel@gmail.com>
To: Jiping Ma <jiping.ma2@windriver.com>, kprateek.nayak@amd.com
Cc: chris.friesen@windriver.com, hanguangjiang@lixiang.com,
linux-kernel@vger.kernel.org, osandov@fb.com,
peterz@infradead.org
Subject: Re: sched: observed instability under stress in 6.12 and mainline
Date: Mon, 13 Oct 2025 13:54:37 +0800 [thread overview]
Message-ID: <b7d9da0c-ee50-173b-3dc9-adcddc64e156@gmail.com> (raw)
In-Reply-To: <20251013030309.2176524-1-jiping.ma2@windriver.com>
On 2025/10/13 11:03, Jiping Ma wrote:
>>> Hi,
>>>
>>> I'd like to draw the attention of the scheduler maintainers to a number
>>> of kernel bugzilla reports submitted by a colleague a couple of weeks ago:
>>>
>>> 6.12.18:
>>> https://bugzilla.kernel.org/show_bug.cgi?id=220447
>>> https://bugzilla.kernel.org/show_bug.cgi?id=220448
>>>
>>> v6.16-rt3
>>> https://bugzilla.kernel.org/show_bug.cgi?id=220450
>>> https://bugzilla.kernel.org/show_bug.cgi?id=220449
>>>
>>> There seems to be something wrong with either the logic or the locking.
>>> In one case this resulted in a NULL pointer dereference in
>>> pick_next_entity(). In another case it resulted in
>>> BUG_ON(!rq->nr_running) in dequeue_top_rt_rq() and
>>> SCHED_WARN_ON(!se->on_rq) in update_entity_lag().
>>>
>>> My colleague suggests that the NULL pointer dereference may be due to
>>> pick_eevdf() returning NULL in pick_next_entity().
>>>
>>> I did some digging and found that
>>> https://gitlab.com/linux-kernel/stable/-/commit/86b37810 would not have
>>> been included in 6.12.18, but the equivalent fix should have been in the
>>> 6.16 load.
>>>
>>> We haven't yet bottomed out the root cause.
>>>
>>> Any suggestions or assistance would be appreciated.
>>>
>>> Thanks,
>>> Chris
>>>
>>>
>>
>> Maybe this patch can be useful for your problem.
>> https://lore.kernel.org/all/tencent_3177343A3163451463643E434C61911B4208@qq.com/
>>
>> If I understand correctly, we may dequeue_entity twice in
>> rt_mutex_setprio()/__sched_setscheduler(). cfs_bandwidth may break the
>> state of p->on_rq and se->on_rq.
>
> Thank veruy much!
> https://lore.kernel.org/all/tencent_3177343A3163451463643E434C61911B4208@qq.com/ can fix the original panic
> https://bugzilla.kernel.org/show_bug.cgi?id=220447, now we encounter the other !se->on_rq WARNING. Do you know
> we already have the fix?
>
Perhaps the following patch is more suitable for fixing the previous panic.
https://lore.kernel.org/all/105ae6f1-f629-4fe7-9644-4242c3bed035@amd.com/
This issue has been resolved in the latest kernel mainline by
refactoring cfs_bandwidth.
As Peter mentioned, we need to submit a separate fix patch for the
stable branch.
https://lore.kernel.org/all/20250929103836.GK3419281@noisy.programming.kicks-ass.net/
Thanks,
Hao
prev parent reply other threads:[~2025-10-13 5:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-04 16:33 sched: observed instability under stress in 6.12 and mainline Chris Friesen
2025-09-08 1:51 ` Hao Jia
2025-09-08 2:22 ` Hao Jia
2025-10-13 3:03 ` Jiping Ma
2025-10-13 5:54 ` Hao Jia [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b7d9da0c-ee50-173b-3dc9-adcddc64e156@gmail.com \
--to=jiahao.kernel@gmail.com \
--cc=chris.friesen@windriver.com \
--cc=hanguangjiang@lixiang.com \
--cc=jiping.ma2@windriver.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=osandov@fb.com \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).