From: Petr Mladek <pmladek@suse.com>
To: syzbot <syzbot+9bc8c0586b39708784d9@syzkaller.appspotmail.com>
Cc: anna.luese@v-bien.de, cem@kernel.org, davem@davemloft.net,
edumazet@google.com, horms@kernel.org, jhs@mojatatu.com,
jiri@resnulli.us, john.ogness@linutronix.de, kuba@kernel.org,
linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org,
netdev@vger.kernel.org, pabeni@redhat.com, rostedt@goodmis.org,
senozhatsky@chromium.org, syzkaller-bugs@googlegroups.com,
xiyou.wangcong@gmail.com
Subject: Re: [syzbot] [xfs?] INFO: task hung in xfs_file_fsync
Date: Wed, 7 Jan 2026 14:00:13 +0100 [thread overview]
Message-ID: <aV5Y3UG7JMJ0iE_i@pathway.suse.cz> (raw)
In-Reply-To: <686f0cd3.050a0220.385921.0023.GAE@google.com>
On Wed 2025-07-09 17:44:03, syzbot wrote:
> syzbot has bisected this issue to:
>
> commit 0161e2d6950fe66cf6ac1c10d945bae971f33667
> Author: John Ogness <john.ogness@linutronix.de>
> Date: Mon Dec 9 11:17:46 2024 +0000
>
> printk: Defer legacy printing when holding printk_cpu_sync
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=14b19a8c580000
Just for record. It looks to me that the bisection was wrong.
The original problem was:
ci starts bisection 2025-07-09 13:22:22.587055103 +0000 UTC m=+182.380303436
bisecting cause commit starting from d006330be3f782ff3fb7c3ed51e617e01f29a465
building syzkaller on abade7941e7b8a888e052cda1a92805ab785c77e
ensuring issue is reproducible on original commit d006330be3f782ff3fb7c3ed51e617e01f29a465
testing commit d006330be3f782ff3fb7c3ed51e617e01f29a465 gcc
compiler: Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
kernel signature: fd86d90e0d4e2b546bda0ba5ad3009b1c803f92f35eefc7a5a9a6a9779edb44a
run #0: crashed: INFO: task hung in xfs_setfilesize
run #1: crashed: INFO: task hung in xfs_setfilesize
run #2: crashed: INFO: task hung in xfs_setfilesize
run #3: crashed: INFO: task hung in process_measurement
run #4: crashed: INFO: task hung in xfs_setfilesize
run #5: crashed: INFO: task hung in process_measurement
run #6: crashed: INFO: task hung in xfs_setfilesize
run #7: crashed: INFO: task hung in process_measurement
run #8: crashed: INFO: task hung in process_measurement
run #9: crashed: INFO: task hung in xfs_setfilesize
run #10: crashed: INFO: task hung in xfs_setfilesize
run #11: crashed: INFO: task hung in xfs_setfilesize
run #12: crashed: INFO: task hung in xfs_setfilesize
run #13: crashed: INFO: task hung in xfs_setfilesize
run #14: crashed: INFO: task hung in xfs_trans_alloc_inode
run #15: crashed: INFO: task hung in xfs_trans_alloc_inode
run #16: crashed: INFO: task hung in xfs_setfilesize
run #17: crashed: INFO: task hung in xfs_setfilesize
run #18: crashed: INFO: task hung in xfs_setfilesize
run #19: crashed: INFO: task hung in xfs_setfilesize
representative crash: INFO: task hung in xfs_setfilesize, types: [HANG]
But the end of the bisection looks like:
testing commit 4ca6c022279dddba1eca8ea580c82ea510ecf690 gcc
compiler: Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
kernel signature: 03f8650641fe155806b39e47c854b91bf96ee0d5e9d18ff940235c5a21c89620
run #0: OK
run #1: OK
run #2: OK
run #3: crashed: BUG: MAX_LOCKDEP_KEYS too low!
run #4: crashed: BUG: MAX_LOCKDEP_KEYS too low!
run #5: crashed: BUG: MAX_LOCKDEP_KEYS too low!
run #6: OK
run #7: crashed: BUG: MAX_LOCKDEP_KEYS too low!
run #8: OK
run #9: OK
run #10: OK
run #11: crashed: BUG: MAX_LOCKDEP_KEYS too low!
run #12: OK
run #13: OK
run #14: OK
run #15: OK
run #16: OK
run #17: OK
run #18: OK
run #19: OK
representative crash: BUG: MAX_LOCKDEP_KEYS too low!, types: [UNKNOWN]
# git bisect bad 4ca6c022279dddba1eca8ea580c82ea510ecf690
Bisecting: 4 revisions left to test after this (roughly 2 steps)
[62de6e1685269e1637a6c6684c8be58cc8d4ff38] Merge tag 'sched-core-2025-01-21' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
testing commit 62de6e1685269e1637a6c6684c8be58cc8d4ff38 gcc
compiler: Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
kernel signature: 8e4e982610da69c055ecca8aaca23f23a454eb4db0ee20d8bf6d5ae22aeebb01
run #0: ignore: lost connection to test machine
run #1: OK
run #2: OK
run #3: OK
run #4: OK
run #5: OK
run #6: OK
run #7: OK
run #8: OK
run #9: OK
run #10: OK
run #11: OK
run #12: OK
run #13: OK
run #14: OK
run #15: OK
run #16: OK
run #17: OK
run #18: OK
run #19: OK
false negative chance: 0.001
# git bisect good 62de6e1685269e1637a6c6684c8be58cc8d4ff38
Bisecting: 2 revisions left to test after this (roughly 1 step)
[0161e2d6950fe66cf6ac1c10d945bae971f33667] printk: Defer legacy printing when holding printk_cpu_sync
testing commit 0161e2d6950fe66cf6ac1c10d945bae971f33667 gcc
compiler: Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
kernel signature: 7566994b210981fb429e3b5e9ed670407710135484fee131b57299dc8b3071f7
run #0: OK
run #1: OK
run #2: OK
run #3: OK
run #4: crashed: BUG: MAX_LOCKDEP_KEYS too low!
run #5: crashed: BUG: MAX_LOCKDEP_KEYS too low!
run #6: crashed: BUG: MAX_LOCKDEP_KEYS too low!
run #7: crashed: BUG: MAX_LOCKDEP_KEYS too low!
run #8: crashed: BUG: MAX_LOCKDEP_KEYS too low!
run #9: crashed: BUG: MAX_LOCKDEP_KEYS too low!
run #10: crashed: BUG: MAX_LOCKDEP_KEYS too low!
run #11: crashed: BUG: MAX_LOCKDEP_KEYS too low!
run #12: crashed: BUG: MAX_LOCKDEP_KEYS too low!
run #13: crashed: BUG: MAX_LOCKDEP_KEYS too low!
run #14: crashed: BUG: MAX_LOCKDEP_KEYS too low!
run #15: crashed: BUG: MAX_LOCKDEP_KEYS too low!
run #16: crashed: BUG: MAX_LOCKDEP_KEYS too low!
run #17: OK
run #18: OK
run #19: OK
representative crash: BUG: MAX_LOCKDEP_KEYS too low!, types: [UNKNOWN]
# git bisect bad 0161e2d6950fe66cf6ac1c10d945bae971f33667
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[f1c21cf470595c4561d4671fd499af94152175d5] printk: Remove redundant deferred check in vprintk()
testing commit f1c21cf470595c4561d4671fd499af94152175d5 gcc
compiler: Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
kernel signature: a7cc6b185bdb5074103099a969663e598b6c2f53f61168a0f2e7c1d9bc9e8426
all runs: OK
false negative chance: 0.001
# git bisect good f1c21cf470595c4561d4671fd499af94152175d5
0161e2d6950fe66cf6ac1c10d945bae971f33667 is the first bad commit
commit 0161e2d6950fe66cf6ac1c10d945bae971f33667
Author: John Ogness <john.ogness@linutronix.de>
Date: Mon Dec 9 12:23:46 2024 +0106
printk: Defer legacy printing when holding printk_cpu_sync
Notice:
=======
The original test crashed with:
crashed: INFO: task hung in xfs_setfilesize
But the bad commits around the potential bad commit are failing
with
crashed: BUG: MAX_LOCKDEP_KEYS too low!
Conclusion:
===========
I believe that the bisection went into a wrong direction.
And the printk() change has nothing to do with a hung task.
Best Regards,
Petr
> start commit: d006330be3f7 Merge tag 'sound-6.16-rc6' of git://git.kerne..
> git tree: upstream
> final oops: https://syzkaller.appspot.com/x/report.txt?x=16b19a8c580000
> console output: https://syzkaller.appspot.com/x/log.txt?x=12b19a8c580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=b309c907eaab29da
> dashboard link: https://syzkaller.appspot.com/bug?extid=9bc8c0586b39708784d9
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15e24a8c580000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10ed3582580000
>
> Reported-by: syzbot+9bc8c0586b39708784d9@syzkaller.appspotmail.com
> Fixes: 0161e2d6950f ("printk: Defer legacy printing when holding printk_cpu_sync")
>
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
next prev parent reply other threads:[~2026-01-07 13:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-09 17:39 syzbot
2025-07-10 0:44 ` syzbot
2026-01-07 13:00 ` Petr Mladek [this message]
2025-12-30 15:21 ` syzbot
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=aV5Y3UG7JMJ0iE_i@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=anna.luese@v-bien.de \
--cc=cem@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=john.ogness@linutronix.de \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
--cc=syzbot+9bc8c0586b39708784d9@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=xiyou.wangcong@gmail.com \
/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
all inboxes | Powered by JetHome®