Thread (3 messages) read the whole thread 3 messages, 2 authors, 2025-08-20

Re: REGRESSION on linux-next (next-20250814)

From: Yu Kuai <hidden>
Date: 2025-08-18 09:35:55
Also in: intel-gfx, intel-xe

Hi,

在 2025/08/18 16:35, Borah, Chaitanya Kumar 写道:
Hello Julian,

Hope you are doing well. I am Chaitanya from the linux graphics team in 
Intel.

This mail is regarding a regression we are seeing in our CI runs[1] on
linux-next repository.

Since the version next-20250814 [2], we are seeing the following regression

````````````````````````````````````````````````````````````````````````````````` 

<4>[   25.645493] ======================================================
<4>[   25.645497] WARNING: possible circular locking dependency detected
<5>[   25.645501] 6.17.0-rc2-next-20250818-next-20250818-g3ac864c2d9bb+ 
#1 Not tainted
<4>[   25.645506] ------------------------------------------------------
<4>[   25.645509] swapper/0/1 is trying to acquire lock:
<5>[   25.645513] ffffffff83488270 (cpu_hotplug_lock){++++}-{0:0}, at: 
static_key_slow_inc+0x12/0x30
<4>[   25.645526]
                   but task is already holding lock:
<5>[   25.645529] ffff8881063fce30 
(&q->q_usage_counter(io)){++++}-{0:0}, at: 
blk_mq_freeze_queue_nomemsave+0x12/0x30
<4>[   25.645540]
                   which lock already depends on the new lock.

<4>[   25.645545]
                   the existing dependency chain (in reverse order) is:
<5>[   25.645549]
                   -> #2 (&q->q_usage_counter(io)){++++}-{0:0}:
<5>[   25.645554]        blk_alloc_queue+0x324/0x360
<5>[   25.645560]        blk_mq_alloc_queue+0x6a/0xe0
<5>[   25.645564]        __blk_mq_alloc_disk+0x19/0x70
<5>[   25.645567]        loop_add+0x240/0x430
<5>[   25.645573]        loop_init+0xcd/0x190
<5>[   25.645576]        do_one_initcall+0x5d/0x3f0
<5>[   25.645581]        kernel_init_freeable+0x3cd/0x6a0
<5>[   25.645586]        kernel_init+0x1b/0x200
<5>[   25.645591]        ret_from_fork+0x26c/0x2e0
<5>[   25.645597]        ret_from_fork_asm+0x1a/0x30
````````````````````````````````````````````````````````````````````````````````` 

Details log can be found in [3].
The bisecting is because this patch actually enable wbt now, while this
patch is not the root cause.

Following is a fix by Nilay, you can have a test if your problem can be
fixed.

https://lore.kernel.org/all/20250814082612.500845-1-nilay@linux.ibm.com/ (local)

Thanks,
Kuai
After bisecting the tree, the following patch [4] seems to be the first 
"bad" commit

````````````````````````````````````````````````````````````````````````````````````````````````````````` 

commit 8f5845e0743bf3512b71b3cb8afe06c192d6acc4
Author: Julian Sun sunjunchao2870@gmail.com
Date:   Tue Aug 12 23:42:57 2025 +0800

     block: restore default wbt enablement
````````````````````````````````````````````````````````````````````````````````````````````````````````` 


We also verified that if we revert the patch the issue is not seen.

Could you please check why the patch causes this regression and provide 
a fix if necessary?

Thank you.

Regards

Chaitanya

[1]
https://intel-gfx-ci.01.org/tree/linux-next/combined-alt.html?
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20250814 

[3] 
https://intel-gfx-ci.01.org/tree/linux-next/next-20250818/bat-twl-1/boot0.txt 

[4] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20250818&id=8f5845e0743bf3512b71b3cb8afe06c192d6acc4 



.
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help