From: CJ <firefly0158@163.com>
To: tytso@mit.edu, adilger.kernel@dilger.ca,
libaokun@linux.alibaba.com, jack@suse.cz, ojaswin@linux.ibm.com
Cc: linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [BUG] ext4: WARNING in lock_two_nondirectories from __ext4_ioctl
Date: Mon, 14 Sep 2026 17:11:24 +0800 (CST) [thread overview]
Message-ID: <72a2177d.8ac9.1a09f2f7a8f.Coremail.firefly0158@163.com> (raw)
Hi,
I am reporting a locking WARNING on the ext4 boot-loader inode swap ioctl,
triggered by a syzkaller reproducer that mounts a crafted ext4 image. The issue
is reproducible with HEAD commit cee9395acd8043be0644b25c34bfa86623f2b935
(v7.3-rc1, Linux 7.3.0-rc1).
The reproducer mounts a crafted ext4 filesystem image without a journal on a
loop device and issues the ioctl that swaps the boot loader inode. The console
shows the mount succeeding with quota and noload options and then the WARNING.
The console shows "WARNING: fs/inode.c:1250 at
lock_two_nondirectories+0x1ad/0x200" with RIP in lock_two_nondirectories,
reached from __ext4_ioctl. On the kernel where this was first reported the same
ioctl path produced a different locking complaint: a bad unlock balance for
&type->i_mutex_dir_key, reported at the rwsem up_write site, again reached from
swap_inode_boot_loader in __ext4_ioctl. Both reports point at the same
lock/unlock handling in the boot-loader swap, but the reported mechanism and
location differ between the two kernels, so I am describing this as a likely
recurrence rather than an identical splat.
One possible cause is that the boot-loader swap path does not take and release
the inode locks in the order lock_two_nondirectories expects, so the inode-level
lock helper warns. This looks like a locking-discipline problem in the ioctl
path rather than a filesystem-format problem. I am reporting the warning and
the path as observed.
This appears to be a recurrence of the syzbot issue whose external id is
77a0245eb4ed995150a6. It remains reproducible on v7.3-rc1.
Reproducer:
syz reproducer: https://pastebin.com/raw/6Bm3KLQe
console output: https://pastebin.com/raw/srNkezze
kernel config: https://pastebin.com/raw/cTQr5iDa
Kernel:
HEAD commit: cee9395acd8043be0644b25c34bfa86623f2b935
git tree: upstream (linux.git), tested through the v7.3-rc1 annotated tag object
e5e04726cdd043e309677071ab1b65a4b18f422b
kernel version: 7.3.0-rc1 #1 PREEMPT(full)
tested tag: v7.3-rc1 (Linux 7.3-rc1, 2026-08-30)
Let me know if you need more details or testing.
Best regards,
reply other threads:[~2026-09-14 9:11 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=72a2177d.8ac9.1a09f2f7a8f.Coremail.firefly0158@163.com \
--to=firefly0158@163.com \
--cc=adilger.kernel@dilger.ca \
--cc=jack@suse.cz \
--cc=libaokun@linux.alibaba.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ojaswin@linux.ibm.com \
--cc=tytso@mit.edu \
/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®