From: Matthew Wilcox <willy@infradead.org>
To: syzbot <syzbot+9c8140e9162432b9eb20@syzkaller.appspotmail.com>
Cc: akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] inconsistent lock state in _atomic_dec_and_lock
Date: Mon, 24 Oct 2022 03:35:53 +0100 [thread overview]
Message-ID: <Y1X6CY0ZoM9/HuNf@casper.infradead.org> (raw)
In-Reply-To: <000000000000cd8af105ebb7e570@google.com>
On Sun, Oct 23, 2022 at 11:32:30AM -0700, syzbot wrote:
> ================================
> WARNING: inconsistent lock state
> 6.0.0-rc7-syzkaller-18095-gbbed346d5a96 #0 Not tainted
> --------------------------------
> inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
> syz-executor.3/9712 [HC0[0]:SC0[0]:HE1:SE1] takes:
> ffff0000d10c2577 (&folio_wait_table[i]){?.-.}-{2:2}, at: spin_lock include/linux/spinlock.h:349 [inline]
> ffff0000d10c2577 (&folio_wait_table[i]){?.-.}-{2:2}, at: _atomic_dec_and_lock+0xc8/0x130 lib/dec_and_lock.c:28
> {IN-HARDIRQ-W} state was registered at:
> lock_acquire+0x100/0x1f8 kernel/locking/lockdep.c:5666
> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
> _raw_spin_lock_irqsave+0x6c/0xb4 kernel/locking/spinlock.c:162
> folio_wake_bit+0x88/0x254 mm/filemap.c:1143
This is clearly complete garbage. If we're using spin_lock_irqsave(),
then we can't have a {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} problem.
> stack backtrace:
> CPU: 1 PID: 9712 Comm: syz-executor.3 Not tainted 6.0.0-rc7-syzkaller-18095-gbbed346d5a96 #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/30/2022
> Call trace:
> dump_backtrace+0x1c4/0x1f0 arch/arm64/kernel/stacktrace.c:156
> show_stack+0x2c/0x54 arch/arm64/kernel/stacktrace.c:163
> __dump_stack lib/dump_stack.c:88 [inline]
> dump_stack_lvl+0x104/0x16c lib/dump_stack.c:106
> dump_stack+0x1c/0x58 lib/dump_stack.c:113
> print_usage_bug+0x39c/0x3cc kernel/locking/lockdep.c:3961
> mark_lock_irq+0x4a8/0x4b4
> mark_lock+0x154/0x1b4 kernel/locking/lockdep.c:4632
> mark_usage kernel/locking/lockdep.c:4541 [inline]
> __lock_acquire+0x5f8/0x30a4 kernel/locking/lockdep.c:5007
> lock_acquire+0x100/0x1f8 kernel/locking/lockdep.c:5666
> __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline]
> _raw_spin_lock+0x54/0x6c kernel/locking/spinlock.c:154
> spin_lock include/linux/spinlock.h:349 [inline]
> _atomic_dec_and_lock+0xc8/0x130 lib/dec_and_lock.c:28
> iput+0x50/0x324 fs/inode.c:1766
> ntfs_fill_super+0x1254/0x14a4 fs/ntfs3/super.c:1190
Oh. ntfs probably corrupted the lockdep state. Also, this is
a completely different lock from the first one. So I'm going to
ignore this report.
prev parent reply other threads:[~2022-10-24 2:35 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-23 18:32 syzbot
2022-10-24 2:35 ` Matthew Wilcox [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=Y1X6CY0ZoM9/HuNf@casper.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=syzbot+9c8140e9162432b9eb20@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.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