* Re: [PATCH v11 08/15] xfs: Report case sensitivity in fileattr_get
From: Darrick J. Wong @ 2026-04-27 15:56 UTC (permalink / raw)
To: Chuck Lever
Cc: Al Viro, Christian Brauner, Jan Kara, linux-fsdevel, linux-ext4,
linux-xfs, linux-cifs, linux-nfs, linux-api, linux-f2fs-devel,
hirofumi, linkinjeon, sj1557.seo, yuezhang.mo,
almaz.alexandrovich, slava, glaubitz, frank.li, tytso,
adilger.kernel, cem, sfrench, pc, ronniesahlberg, sprasad,
trondmy, anna, jaegeuk, chao, hansg, senozhatsky, Chuck Lever,
Roland Mainz
In-Reply-To: <20260424-case-sensitivity-v11-8-de5619beddaf@oracle.com>
On Fri, Apr 24, 2026 at 09:53:10PM -0400, Chuck Lever wrote:
> From: Chuck Lever <chuck.lever@oracle.com>
>
> Upper layers such as NFSD need to query whether a filesystem
> is case-sensitive. Add FS_XFLAG_CASEFOLD to xfs_ip2xflags()
> when the filesystem is formatted with the ASCIICI feature
> flag. This serves both FS_IOC_FSGETXATTR (via xfs_fill_fsxattr() in
> xfs_fileattr_get()) and XFS_IOC_BULKSTAT (which populates bs_xflags
> directly from xfs_ip2xflags()), so bulkstat consumers and per-inode
> queries see a consistent view of the filesystem's case-folding
> behavior.
>
> XFS always preserves case. XFS is case-sensitive by default, but
> supports ASCII case-insensitive lookups when formatted with the
> ASCIICI feature flag.
>
> Reviewed-by: Roland Mainz <roland.mainz@nrubsig.org>
> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
> ---
> fs/xfs/libxfs/xfs_inode_util.c | 2 ++
> fs/xfs/xfs_ioctl.c | 7 +++++++
> 2 files changed, 9 insertions(+)
>
> diff --git a/fs/xfs/libxfs/xfs_inode_util.c b/fs/xfs/libxfs/xfs_inode_util.c
> index 551fa51befb6..82be54b6f8d3 100644
> --- a/fs/xfs/libxfs/xfs_inode_util.c
> +++ b/fs/xfs/libxfs/xfs_inode_util.c
> @@ -130,6 +130,8 @@ xfs_ip2xflags(
>
> if (xfs_inode_has_attr_fork(ip))
> flags |= FS_XFLAG_HASATTR;
> + if (xfs_has_asciici(ip->i_mount))
> + flags |= FS_XFLAG_CASEFOLD;
> return flags;
> }
>
> diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
> index ed9b4846c05f..5a58fb0bad2b 100644
> --- a/fs/xfs/xfs_ioctl.c
> +++ b/fs/xfs/xfs_ioctl.c
> @@ -472,6 +472,13 @@ xfs_fill_fsxattr(
>
> fileattr_fill_xflags(fa, xfs_ip2xflags(ip));
>
> + /*
> + * FS_XFLAG_CASEFOLD is read-only; hide it from the legacy
> + * flags view so chattr's RMW cycle does not pass it back to
> + * xfs_fileattr_set().
> + */
> + fa->flags &= ~FS_CASEFOLD_FL;
I don't understand this at all. Yes, FS_XFLAG_CASEFOLD is readonly, but
how does clearing FS_CASEFOLD_FL from the fileattr_get output (without
clearing XFLAG_CASEFOLD!) solve anything? This makes the reported
output inconsistent between fsgetxattr and getflags -- one reports case
folding, the other reports no casefolding.
If you want to avoid fileattr_set returning EINVAL when setting
attributes due to the casefold flag, then don't you want to check the
flag state vs. xfs_has_asciici() in the *fileattr_set* path?
--D
> +
> if (ip->i_diflags & XFS_DIFLAG_EXTSIZE) {
> fa->fsx_extsize = XFS_FSB_TO_B(mp, ip->i_extsize);
> } else if (ip->i_diflags & XFS_DIFLAG_EXTSZINHERIT) {
>
> --
> 2.53.0
>
>
^ permalink raw reply
* Re: [PATCH v11 00/15] Exposing case folding behavior
From: Jan Kara @ 2026-04-27 15:30 UTC (permalink / raw)
To: Chuck Lever
Cc: Jan Kara, Alexander Viro, Christian Brauner, linux-fsdevel,
linux-ext4, linux-xfs, linux-cifs, linux-nfs, linux-api,
linux-f2fs-devel, OGAWA Hirofumi, Namjae Jeon, Sungjong Seo,
Yuezhang Mo, almaz.alexandrovich, Viacheslav Dubeyko,
John Paul Adrian Glaubitz, frank.li, Theodore Tso, adilger.kernel,
Carlos Maiolino, Steve French, Paulo Alcantara, Ronnie Sahlberg,
Shyam Prasad N, Trond Myklebust, Anna Schumaker, Jaegeuk Kim,
Chao Yu, Hans de Goede, senozhatsky, Chuck Lever, Darrick J. Wong,
Roland Mainz, Steve French
In-Reply-To: <af3f7518-7501-4c25-9bbc-a8fc8cdb4e29@app.fastmail.com>
On Mon 27-04-26 09:30:28, Chuck Lever wrote:
>
> On Mon, Apr 27, 2026, at 6:55 AM, Jan Kara wrote:
> > On Fri 24-04-26 21:53:02, Chuck Lever wrote:
> >> Changes since v10:
> >> - cifs: Source case-handling flags from the server's cached
> >> FS_ATTRIBUTE_INFORMATION reply instead of the nocase mount
> >> option, with a nocase fallback when the reply is absent
> >> - Address findings from sashiko(gemini-3) and gpt-5.5:
> >> - nfs: Skip pathconf case bits on NFSv4 (set via FATTR4_CASE_*
> >> instead)
> >> - xfs: Hide FS_CASEFOLD_FL from the legacy flags view so
> >> chattr round-trips do not hit the setflags whitelist
> >> - ext4, f2fs: Drop redundant fileattr_get patches; the
> >> FS_CASEFOLD_FL translation in fileattr_fill_flags() already
> >> reports FS_XFLAG_CASEFOLD for casefolded directories
> >
> > Err, how is this supposed to work? I wasn't able to find any code
> > transforming S_CASEFOLDED inode flag into FS_CASEFOLD_FL on fileattr_get
> > path. Sure, fileattr_fill_flags() takes care of setting FS_XFLAG_CASEFOLD
> > once FS_CASEFOLD_FL is set. What am I missing?
>
> Agreed, that is a little surprising.
>
> The path does not go through S_CASEFOLD. Both filesystems
> report FS_CASEFOLD_FL straight from their on-disk flag word.
>
> For ext4, EXT4_CASEFOLD_FL is 0x40000000, the same bit value
> as FS_CASEFOLD_FL, and it is included in EXT4_FL_USER_VISIBLE.
> ext4_iget() loads it into ei->i_flags directly from
> raw_inode->i_flags (fs/ext4/inode.c:5358). ext4_fileattr_get()
> then masks with EXT4_FL_USER_VISIBLE and hands the result to
> fileattr_fill_flags(), which translates FS_CASEFOLD_FL into
> FS_XFLAG_CASEFOLD on the way out.
Oh, right. I've missed how EXT4_CASEFOLD_FL propagates into FS_CASEFOLD_FL.
Thanks for clearing that out.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: [PATCH v11 00/15] Exposing case folding behavior
From: Chuck Lever @ 2026-04-27 13:30 UTC (permalink / raw)
To: Jan Kara
Cc: Alexander Viro, Christian Brauner, linux-fsdevel, linux-ext4,
linux-xfs, linux-cifs, linux-nfs, linux-api, linux-f2fs-devel,
OGAWA Hirofumi, Namjae Jeon, Sungjong Seo, Yuezhang Mo,
almaz.alexandrovich, Viacheslav Dubeyko,
John Paul Adrian Glaubitz, frank.li, Theodore Tso, adilger.kernel,
Carlos Maiolino, Steve French, Paulo Alcantara, Ronnie Sahlberg,
Shyam Prasad N, Trond Myklebust, Anna Schumaker, Jaegeuk Kim,
Chao Yu, Hans de Goede, senozhatsky, Chuck Lever, Darrick J. Wong,
Roland Mainz, Steve French
In-Reply-To: <yc7ygk6w6zvf46arzzvmxnuoqjrni2dtlhmywaivzmvfxnilf3@xv7tthtrowns>
On Mon, Apr 27, 2026, at 6:55 AM, Jan Kara wrote:
> On Fri 24-04-26 21:53:02, Chuck Lever wrote:
>> Changes since v10:
>> - cifs: Source case-handling flags from the server's cached
>> FS_ATTRIBUTE_INFORMATION reply instead of the nocase mount
>> option, with a nocase fallback when the reply is absent
>> - Address findings from sashiko(gemini-3) and gpt-5.5:
>> - nfs: Skip pathconf case bits on NFSv4 (set via FATTR4_CASE_*
>> instead)
>> - xfs: Hide FS_CASEFOLD_FL from the legacy flags view so
>> chattr round-trips do not hit the setflags whitelist
>> - ext4, f2fs: Drop redundant fileattr_get patches; the
>> FS_CASEFOLD_FL translation in fileattr_fill_flags() already
>> reports FS_XFLAG_CASEFOLD for casefolded directories
>
> Err, how is this supposed to work? I wasn't able to find any code
> transforming S_CASEFOLDED inode flag into FS_CASEFOLD_FL on fileattr_get
> path. Sure, fileattr_fill_flags() takes care of setting FS_XFLAG_CASEFOLD
> once FS_CASEFOLD_FL is set. What am I missing?
Agreed, that is a little surprising.
The path does not go through S_CASEFOLD. Both filesystems
report FS_CASEFOLD_FL straight from their on-disk flag word.
For ext4, EXT4_CASEFOLD_FL is 0x40000000, the same bit value
as FS_CASEFOLD_FL, and it is included in EXT4_FL_USER_VISIBLE.
ext4_iget() loads it into ei->i_flags directly from
raw_inode->i_flags (fs/ext4/inode.c:5358). ext4_fileattr_get()
then masks with EXT4_FL_USER_VISIBLE and hands the result to
fileattr_fill_flags(), which translates FS_CASEFOLD_FL into
FS_XFLAG_CASEFOLD on the way out.
For f2fs, f2fs_fileattr_get() runs fi->i_flags through
f2fs_iflags_to_fsflags(), whose mapping table has an explicit
{ F2FS_CASEFOLD_FL, FS_CASEFOLD_FL } entry (fs/f2fs/file.c:2205).
F2FS_GETTABLE_FS_FL includes FS_CASEFOLD_FL, so
fileattr_fill_flags() again lights up FS_XFLAG_CASEFOLD.
S_CASEFOLD is a separate VFS-level cache that
ext4_set_inode_flags() and f2fs's equivalent set at iget
time; nothing on the fileattr_get path consults it.
For reference, the original observation about the manual
assignment being redundant came from sashiko's review of v10:
https://sashiko.dev/#/patchset/20260423-case-sensitivity-v10-0-c385d674a6cf%40oracle.com?part=8
https://sashiko.dev/#/patchset/20260423-case-sensitivity-v10-0-c385d674a6cf%40oracle.com?part=12
--
Chuck Lever
^ permalink raw reply
* Re: [PATCH v11 12/15] isofs: Implement fileattr_get for case sensitivity
From: Jan Kara @ 2026-04-27 13:30 UTC (permalink / raw)
To: Lionel Cons
Cc: Jan Kara, Chuck Lever, Al Viro, Christian Brauner, linux-fsdevel,
linux-ext4, linux-xfs, linux-cifs, linux-nfs, linux-api,
linux-f2fs-devel, hirofumi, linkinjeon, sj1557.seo, yuezhang.mo,
almaz.alexandrovich, slava, glaubitz, frank.li, tytso,
adilger.kernel, cem, sfrench, pc, ronniesahlberg, sprasad,
trondmy, anna, jaegeuk, chao, hansg, senozhatsky, Chuck Lever,
Roland Mainz
In-Reply-To: <CAPJSo4WmRu_64TxBsaimWOqz3VAU0TZ1H-_hw36HSqzQULm39w@mail.gmail.com>
On Mon 27-04-26 14:02:00, Lionel Cons wrote:
> On Mon, 27 Apr 2026 at 12:47, Jan Kara <jack@suse.cz> wrote:
> >
> > On Fri 24-04-26 21:53:14, Chuck Lever wrote:
> > > From: Chuck Lever <chuck.lever@oracle.com>
> > >
> > > Upper layers such as NFSD need a way to query whether a
> > > filesystem handles filenames in a case-sensitive manner so
> > > they can provide correct semantics to remote clients. Without
> > > this information, NFS exports of ISO 9660 filesystems cannot
> > > advertise their filename case behavior.
> > >
> > > Implement isofs_fileattr_get() to report ISO 9660 case handling
> > > behavior via the FS_XFLAG_CASEFOLD flag. The 'check=r' (relaxed)
> > > mount option enables case-insensitive lookups, and this setting
> > > determines the value reported. By default, Joliet extensions
> > > operate in relaxed mode while plain ISO 9660 uses strict
> > > (case-sensitive) mode. All ISO 9660 variants are case-preserving,
> > > meaning filenames are stored exactly as they appear on the disc.
> > >
> > > Case handling is a superblock-wide property, so the callback
> > > must report the same value for every inode type. Regular files
> > > previously had no inode_operations; introduce
> > > isofs_file_inode_operations to carry the callback. Symlinks
> > > previously shared page_symlink_inode_operations; introduce
> > > isofs_symlink_inode_operations, which wires page_get_link
> > > alongside the callback, so that fileattr queries on a symlink
> > > reach the isofs implementation instead of returning
> > > -ENOIOCTLCMD. The flag is set in both fa->fsx_xflags and
> > > fa->flags so FS_IOC_FSGETXATTR and FS_IOC_GETFLAGS agree.
> > >
> > > Reviewed-by: Jan Kara <jack@suse.cz>
> > > Reviewed-by: Roland Mainz <roland.mainz@nrubsig.org>
> > > Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
> >
> > ...
> >
> > > @@ -281,6 +293,18 @@ const struct file_operations isofs_dir_operations =
> > > const struct inode_operations isofs_dir_inode_operations =
> > > {
> > > .lookup = isofs_lookup,
> > > + .fileattr_get = isofs_fileattr_get,
> > > +};
> > > +
> > > +const struct inode_operations isofs_file_inode_operations =
> > > +{
> > > + .fileattr_get = isofs_fileattr_get,
> > > +};
> > > +
> > > +const struct inode_operations isofs_symlink_inode_operations =
> > > +{
> > > + .get_link = page_get_link,
> > > + .fileattr_get = isofs_fileattr_get,
> > > };
> >
> > Hum, I thought casefolding is a directory attribute. At least I don't see
> > a big point in reporting it for regular files or symlinks (and then why not
> > report it for device nodes or named pipes?). So why did you decide for this
> > change?
>
> Where do you see this being a per-directory attribute in
> https://web.archive.org/web/20170404043745/http://www.ymi.com/ymi/sites/default/files/pdf/Rockridge.pdf
I wasn't refering to Rockridge standard but rather to the general way how
VFS tracks (and reports) casefolding.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: [PATCH v2] generic/790: test post-EOF gap zeroing persistence
From: Brian Foster @ 2026-04-27 13:03 UTC (permalink / raw)
To: Zhang Yi
Cc: fstests, zlang, linux-ext4, linux-fsdevel, jack, yi.zhang,
yizhang089, yangerkun
In-Reply-To: <038228d9-8058-43e0-8be9-b8afc9e8397c@huaweicloud.com>
On Sat, Apr 25, 2026 at 11:06:27AM +0800, Zhang Yi wrote:
> On 4/24/2026 9:09 PM, Brian Foster wrote:
> > On Fri, Apr 24, 2026 at 05:22:28PM +0800, Zhang Yi wrote:
> >> From: Zhang Yi <yi.zhang@huawei.com>
> >>
> >> Test that extending a file past a non-block-aligned EOF correctly
> >> zero-fills the gap [old_EOF, block_boundary), and that this zeroing
> >> persists through a filesystem shutdown+remount cycle.
> >>
> >> Stale data beyond EOF can persist on disk when append write data blocks
> >> are flushed before the on-disk file size update, or when concurrent
> >> append writeback and mmap writes persist non-zero data past EOF.
> >> Subsequent post-EOF operations (append write, fallocate, truncate up)
> >> must zero-fill and persist the gap to prevent exposing stale data.
> >>
> >> The test pollutes the file's last physical block (via FIEMAP + raw
> >> device write) with a sentinel pattern beyond i_size, then performs each
> >> extend operation and verifies the gap is zeroed both in memory and on
> >> disk.
> >>
> >> Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
> >> ---
> >> v1->v2:
> >> - Add _require_no_realtime to prevent testing on XFS realtime devices,
> >> where file data may reside on $SCRATCH_RTDEV.
> >> - Add _exclude_fs btrfs since FIEMAP returns logical addresses, not
> >> physical device offsets, writing to these offsets on $SCRATCH_DEV
> >> would corrupt the filesystem in multi-device setups. Besides, since
> >> btrfs doesn't support shutdown right now, we can support it later.
> >> - Add -v flag to od in _check_gap_zero() to prevent line folding of
> >> identical consecutive lines.
> >> - Add expected_new_sz parameter to _test_eof_zeroing(), verify file
> >> size was not rolled back after shutdown+remount cycle, and also drop
> >> the unnecessary file size check before the shutdown as well.
> >> - Clarify the comment regarding when stale data beyond EOF can persist.
> >>
> >
> > Thanks for the tweaks. This all LGTM from a review standpoint. I gave it
> > a quick test on latest master and I see a few failures in a couple runs:
> >
> > - On XFS (mkfs defaults) I saw one unexpected i_size failure and one
> > zeroing failure, both on write extension fwiw.
>
> Previously, I only discovered the zeroing failure of append write. This
> is because xfs_file_write_checks() -> xfs_file_write_zero_eof() only
> zeroes the gap range in the page cache, without providing any
> synchronous or asynchronous persistence (instead, truncate up does
> synchronously writeback in xfs_vn_setattr_size(), and ext4 achieves
> persistence via asynchronous writeback in data=ordered mode). So I think
> this is a XFS problem.
>
Ah Ok.. the truncate flush has been there for a while to combat the NULL
files problem, and the zeroing check ties into that. I suspect the
reason we don't see this often is typical ascending offset writeback
order, whereas this test is doing a targeted sync range of a later
offset in the file (i.e. technically not overlapping with the range that
was zeroed internally).
I guess the simple thing to do there would be to similarly flush on
write extension. I'd want to think about that just a bit because we
haven't historically flushed there and I know the zeroing improvements
I've made in iomap have caused a couple performance regressions along
the way related to aggressive flushing that had to be fixed.
Maybe this is less of an issue now, but regardless if my assumptions are
correct here than I agree this isn't a test issue.
> Regarding the i_size failure, I did not directly reproduce this issue.
> After analysis, I believe it is because the test case did not include
> the -a option in sync_range, meaning it did not wait for IO writeback
> completion and file size update persistence. I reproduced this issue by
> adding a delay in the XFS end IO path. This is a problem with the test
> case, and I will fix it in v3. Thank you for pointing this out.
>
Makes sense. It will be interesting to see if we can still reproduce the
above issue with this change.
> > - On ext4 I saw a few unexpected i_size failures (both with mkfs
> > defaults and 1k block size).
> >
>
> This is an ext4 issue on the shutdown path. Since ext4 set the shutdown
> flag too early, it was unable to write back ordered zero data when
> flushing the journal, which led to a journal abort and prevented the file
> size update from being persisted. I have submitted a patch to fix this
> issue. Please see below link for details.
>
> https://lore.kernel.org/linux-ext4/20260424104201.1930823-1-yi.zhang@huaweicloud.com/
>
Ok, thanks.
Brian
> Thanks
> Yi.
>
> > I haven't dug into anything beyond that. Does this match what you're
> > seeing on current kernels or are these unexpected failures?
> >
> > Brian
> >
> >> tests/generic/790 | 164 ++++++++++++++++++++++++++++++++++++++++++
> >> tests/generic/790.out | 4 ++
> >> 2 files changed, 168 insertions(+)
> >> create mode 100755 tests/generic/790
> >> create mode 100644 tests/generic/790.out
> >>
> >> diff --git a/tests/generic/790 b/tests/generic/790
> >> new file mode 100755
> >> index 00000000..2adc06f8
> >> --- /dev/null
> >> +++ b/tests/generic/790
> >> @@ -0,0 +1,164 @@
> >> +#! /bin/bash
> >> +# SPDX-License-Identifier: GPL-2.0
> >> +# Copyright (c) 2026 Huawei. All Rights Reserved.
> >> +#
> >> +# FS QA Test No. 790
> >> +#
> >> +# Test that extending a file past a non-block-aligned EOF correctly zero-fills
> >> +# the gap [old_EOF, block_boundary), and that this zeroing persists through a
> >> +# filesystem shutdown+remount cycle.
> >> +#
> >> +# Stale data beyond EOF can persist on disk when:
> >> +# 1) append write data blocks are flushed before the on-disk file size update,
> >> +# and the system crashes in this window.
> >> +# 2) concurrent append writeback and mmap writes persist non-zero data past EOF.
> >> +#
> >> +# Subsequent post-EOF operations (append write, fallocate, truncate up) must
> >> +# zero-fill and persist the gap to prevent exposing stale data.
> >> +#
> >> +# The test pollutes the file's last physical block (via FIEMAP + raw device
> >> +# write) with a sentinel pattern beyond i_size, then performs each extend
> >> +# operation and verifies the gap is zeroed both in memory and on disk.
> >> +#
> >> +. ./common/preamble
> >> +_begin_fstest auto quick rw shutdown
> >> +
> >> +. ./common/filter
> >> +
> >> +_require_scratch
> >> +_require_block_device $SCRATCH_DEV
> >> +_require_no_realtime
> >> +_require_scratch_shutdown
> >> +_require_metadata_journaling $SCRATCH_DEV
> >> +
> >> +# FIEMAP on Btrfs returns logical addresses within the filesystem's address
> >> +# space, not physical device offsets. Writing to these offsets on $SCRATCH_DEV
> >> +# would corrupt the filesystem in multi-device setups.
> >> +_exclude_fs btrfs
> >> +
> >> +_require_xfs_io_command "fiemap"
> >> +_require_xfs_io_command "falloc"
> >> +_require_xfs_io_command "pwrite"
> >> +_require_xfs_io_command "truncate"
> >> +_require_xfs_io_command "sync_range"
> >> +
> >> +# Check that gap region [offset, offset+nbytes) is entirely zero
> >> +_check_gap_zero()
> >> +{
> >> + local file="$1"
> >> + local offset="$2"
> >> + local nbytes="$3"
> >> + local label="$4"
> >> + local data
> >> + local stripped
> >> +
> >> + data=$(od -A n -t x1 -v -j $offset -N $nbytes "$file" 2>/dev/null)
> >> +
> >> + # Remove whitespace and check if any byte is non-zero
> >> + stripped=$(printf '%s' "$data" | tr -d ' \n\t')
> >> + if [ -n "$stripped" ] && ! echo "$stripped" | grep -qE "^0+$"; then
> >> + echo "FAIL: non-zero data in gap [$offset,$((offset + nbytes))) $label"
> >> + _hexdump -N $((offset + nbytes)) "$file"
> >> + return 1
> >> + fi
> >> + return 0
> >> +}
> >> +
> >> +# Get the physical block offset (in bytes) of the file's first block on device
> >> +_get_phys_offset()
> >> +{
> >> + local file="$1"
> >> + local fiemap_output
> >> + local phys_blk
> >> +
> >> + fiemap_output=$($XFS_IO_PROG -r -c "fiemap -v" "$file" 2>/dev/null)
> >> + phys_blk=$(echo "$fiemap_output" | _filter_xfs_io_fiemap | head -1 | awk '{print $3}')
> >> + if [ -z "$phys_blk" ]; then
> >> + echo ""
> >> + return
> >> + fi
> >> + # Convert 512-byte blocks to bytes
> >> + echo $((phys_blk * 512))
> >> +}
> >> +
> >> +_test_eof_zeroing()
> >> +{
> >> + local test_name="$1"
> >> + local extend_cmd="$2"
> >> + local expected_new_sz="$3"
> >> + local file=$SCRATCH_MNT/testfile_${test_name}
> >> +
> >> + echo "$test_name" | tee -a $seqres.full
> >> +
> >> + # Compute non-block-aligned EOF offset
> >> + local gap_bytes=16
> >> + local eof_offset=$((blksz - gap_bytes))
> >> +
> >> + # Step 1: Write one full block to ensure the filesystem allocates a
> >> + # physical block for the file instead of using inline data.
> >> + $XFS_IO_PROG -f -c "pwrite -S 0x5a 0 $blksz" -c fsync \
> >> + "$file" >> $seqres.full 2>&1
> >> +
> >> + # Step 2: Get physical block offset on device via FIEMAP
> >> + local phys_offset
> >> + phys_offset=$(_get_phys_offset "$file")
> >> + if [ -z "$phys_offset" ]; then
> >> + _fail "$test_name: failed to get physical block offset via fiemap"
> >> + fi
> >> +
> >> + # Step 3: Truncate file to non-block-aligned size and fsync.
> >> + # The on-disk region [eof_offset, blksz) may or may not be
> >> + # zeroed by the filesystem at this point.
> >> + $XFS_IO_PROG -c "truncate $eof_offset" -c fsync \
> >> + "$file" >> $seqres.full 2>&1
> >> +
> >> + # Step 4: Unmount and restore the physical block to all-0x5a on disk.
> >> + # This bypasses the kernel's pagecache EOF-zeroing to ensure
> >> + # the stale pattern is present on disk. Then remount.
> >> + _scratch_unmount
> >> + $XFS_IO_PROG -d -c "pwrite -S 0x5a $phys_offset $blksz" \
> >> + $SCRATCH_DEV >> $seqres.full 2>&1
> >> + _scratch_mount >> $seqres.full 2>&1
> >> +
> >> + # Step 5: Execute the extend operation.
> >> + $XFS_IO_PROG -c "$extend_cmd" "$file" >> $seqres.full 2>&1
> >> +
> >> + # Step 6: Verify gap [eof_offset, blksz) is zeroed BEFORE shutdown
> >> + _check_gap_zero "$file" $eof_offset $gap_bytes "before shutdown" || return 1
> >> +
> >> + # Step 7: Sync the extended range and shutdown the filesystem with
> >> + # journal flush. This persists the file size extending, and
> >> + # the filesystem should persist the zeroed data in the gap
> >> + # range as well.
> >> + if [ "$extend_cmd" != "${extend_cmd#pwrite}" ]; then
> >> + $XFS_IO_PROG -c "sync_range -w $blksz $blksz" \
> >> + "$file" >> $seqres.full 2>&1
> >> + fi
> >> + _scratch_shutdown -f
> >> +
> >> + # Step 8: Remount and verify gap is still zeroed
> >> + _scratch_cycle_mount
> >> +
> >> + # Verify file size was not rolled back after shutdown+remount
> >> + local sz
> >> + sz=$(stat -c %s "$file")
> >> + if [ "$sz" -ne "$expected_new_sz" ]; then
> >> + _fail "$test_name: file size rolled back after shutdown+remount: $sz != $expected_new_sz"
> >> + fi
> >> +
> >> + _check_gap_zero "$file" $eof_offset $gap_bytes "after shutdown+remount" || return 1
> >> +}
> >> +
> >> +_scratch_mkfs >> $seqres.full 2>&1
> >> +_scratch_mount
> >> +
> >> +blksz=$(_get_block_size $SCRATCH_MNT)
> >> +
> >> +# Test three variants of EOF-extending operations
> >> +_test_eof_zeroing "append_write" "pwrite -S 0x42 $blksz $blksz" $((blksz * 2))
> >> +_test_eof_zeroing "truncate_up" "truncate $((blksz * 2))" $((blksz * 2))
> >> +_test_eof_zeroing "fallocate" "falloc $blksz $blksz" $((blksz * 2))
> >> +
> >> +# success, all done
> >> +status=0
> >> +exit
> >> diff --git a/tests/generic/790.out b/tests/generic/790.out
> >> new file mode 100644
> >> index 00000000..e5e2cc09
> >> --- /dev/null
> >> +++ b/tests/generic/790.out
> >> @@ -0,0 +1,4 @@
> >> +QA output created by 790
> >> +append_write
> >> +truncate_up
> >> +fallocate
> >> --
> >> 2.52.0
> >>
>
^ permalink raw reply
* Re: [PATCH v11 12/15] isofs: Implement fileattr_get for case sensitivity
From: Lionel Cons @ 2026-04-27 12:02 UTC (permalink / raw)
To: Jan Kara
Cc: Chuck Lever, Al Viro, Christian Brauner, linux-fsdevel,
linux-ext4, linux-xfs, linux-cifs, linux-nfs, linux-api,
linux-f2fs-devel, hirofumi, linkinjeon, sj1557.seo, yuezhang.mo,
almaz.alexandrovich, slava, glaubitz, frank.li, tytso,
adilger.kernel, cem, sfrench, pc, ronniesahlberg, sprasad,
trondmy, anna, jaegeuk, chao, hansg, senozhatsky, Chuck Lever,
Roland Mainz
In-Reply-To: <isfgwmd5hxjfn7dj7p54yzlhumx2hrkt3zw7fscs2ywm57g3hu@co27drpx24lq>
On Mon, 27 Apr 2026 at 12:47, Jan Kara <jack@suse.cz> wrote:
>
> On Fri 24-04-26 21:53:14, Chuck Lever wrote:
> > From: Chuck Lever <chuck.lever@oracle.com>
> >
> > Upper layers such as NFSD need a way to query whether a
> > filesystem handles filenames in a case-sensitive manner so
> > they can provide correct semantics to remote clients. Without
> > this information, NFS exports of ISO 9660 filesystems cannot
> > advertise their filename case behavior.
> >
> > Implement isofs_fileattr_get() to report ISO 9660 case handling
> > behavior via the FS_XFLAG_CASEFOLD flag. The 'check=r' (relaxed)
> > mount option enables case-insensitive lookups, and this setting
> > determines the value reported. By default, Joliet extensions
> > operate in relaxed mode while plain ISO 9660 uses strict
> > (case-sensitive) mode. All ISO 9660 variants are case-preserving,
> > meaning filenames are stored exactly as they appear on the disc.
> >
> > Case handling is a superblock-wide property, so the callback
> > must report the same value for every inode type. Regular files
> > previously had no inode_operations; introduce
> > isofs_file_inode_operations to carry the callback. Symlinks
> > previously shared page_symlink_inode_operations; introduce
> > isofs_symlink_inode_operations, which wires page_get_link
> > alongside the callback, so that fileattr queries on a symlink
> > reach the isofs implementation instead of returning
> > -ENOIOCTLCMD. The flag is set in both fa->fsx_xflags and
> > fa->flags so FS_IOC_FSGETXATTR and FS_IOC_GETFLAGS agree.
> >
> > Reviewed-by: Jan Kara <jack@suse.cz>
> > Reviewed-by: Roland Mainz <roland.mainz@nrubsig.org>
> > Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
>
> ...
>
> > @@ -281,6 +293,18 @@ const struct file_operations isofs_dir_operations =
> > const struct inode_operations isofs_dir_inode_operations =
> > {
> > .lookup = isofs_lookup,
> > + .fileattr_get = isofs_fileattr_get,
> > +};
> > +
> > +const struct inode_operations isofs_file_inode_operations =
> > +{
> > + .fileattr_get = isofs_fileattr_get,
> > +};
> > +
> > +const struct inode_operations isofs_symlink_inode_operations =
> > +{
> > + .get_link = page_get_link,
> > + .fileattr_get = isofs_fileattr_get,
> > };
>
> Hum, I thought casefolding is a directory attribute. At least I don't see
> a big point in reporting it for regular files or symlinks (and then why not
> report it for device nodes or named pipes?). So why did you decide for this
> change?
Where do you see this being a per-directory attribute in
https://web.archive.org/web/20170404043745/http://www.ymi.com/ymi/sites/default/files/pdf/Rockridge.pdf
Lionel
^ permalink raw reply
* Re: [PATCH] ext4: fix LOGFLUSH shutdown ordering to allow ordered-mode data writeback
From: Baokun Li @ 2026-04-27 11:23 UTC (permalink / raw)
To: Zhang Yi
Cc: linux-ext4, linux-fsdevel, linux-kernel, tytso, adilger.kernel,
jack, ojaswin, ritesh.list, yi.zhang, yizhang089, yangerkun,
yukuai
In-Reply-To: <20260424104201.1930823-1-yi.zhang@huaweicloud.com>
On 2026/4/24 18:42, Zhang Yi wrote:
> From: Zhang Yi <yi.zhang@huawei.com>
>
> In EXT4_GOING_FLAGS_LOGFLUSH mode, the EXT4_FLAGS_SHUTDOWN flag was set
> before calling ext4_force_commit(). This caused ordered-mode data
> writeback (triggered by journal commit) to fail with -EIO, since
> ext4_do_writepages() checks for the shutdown flag. The journal would
> then be aborted prematurely before the commit could succeed.
>
> Fix this by calling ext4_force_commit() first, then setting the
> shutdown flag, so that pending data can be written back correctly.
>
> Note that moving ext4_force_commit() before setting the shutdown flag
> creates a small window in which new writes may occur and generate new
> journal transactions. When the journal is subsequently aborted, the
> new transactions will not be able to write to disk. This is intentional
> because LOGFLUSH's semantics are to flush pre-existing journal entries
> before shutdown, not to guarantee atomicity for writes that race with
> the ioctl.
>
> Fixes: 783d94854499 ("ext4: add EXT4_IOC_GOINGDOWN ioctl")
> Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
Looks good to me.
Reviewed-by: Baokun Li <libaokun@linux.alibaba.com>
> ---
> This fix addresses my new generic/970 test, which fails during the file
> size verification after shutdown and remount.
>
> https://lore.kernel.org/fstests/20260424092228.1396658-1-yi.zhang@huaweicloud.com/
>
> fs/ext4/ioctl.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
> index 1d0c3d4bdf47..110e3fb194ec 100644
> --- a/fs/ext4/ioctl.c
> +++ b/fs/ext4/ioctl.c
> @@ -830,11 +830,17 @@ int ext4_force_shutdown(struct super_block *sb, u32 flags)
> bdev_thaw(sb->s_bdev);
> break;
> case EXT4_GOING_FLAGS_LOGFLUSH:
> + /*
> + * Call ext4_force_commit() before setting EXT4_FLAGS_SHUTDOWN.
> + * This is because in data=ordered mode, journal commit
> + * triggers data writeback which fails if shutdown is already
> + * set, causing the journal to be aborted prematurely before
> + * the commit succeeds.
> + */
> + (void) ext4_force_commit(sb);
> set_bit(EXT4_FLAGS_SHUTDOWN, &sbi->s_ext4_flags);
> - if (sbi->s_journal && !is_journal_aborted(sbi->s_journal)) {
> - (void) ext4_force_commit(sb);
> + if (sbi->s_journal && !is_journal_aborted(sbi->s_journal))
> jbd2_journal_abort(sbi->s_journal, -ESHUTDOWN);
> - }
> break;
> case EXT4_GOING_FLAGS_NOLOGFLUSH:
> set_bit(EXT4_FLAGS_SHUTDOWN, &sbi->s_ext4_flags);
^ permalink raw reply
* Re: [BUG] ext4: BUG_ON in ext4_write_inline_data (fs/ext4/inline.c:240)
From: Jan Kara @ 2026-04-27 11:17 UTC (permalink / raw)
To: Demi Marie Obenour
Cc: Theodore Tso, Zw Tang, Andreas Dilger, libaokun, jack, ojaswin,
linux-ext4, linux-kernel, yi.zhang, syzkaller-bugs
In-Reply-To: <4e76eb68-862d-4b9f-8242-e6aced2704ee@gmail.com>
On Sat 25-04-26 14:00:23, Demi Marie Obenour wrote:
> On 4/21/26 08:20, Theodore Tso wrote:
> > On Tue, Apr 21, 2026 at 07:32:43PM +0800, Zw Tang wrote:
> >> This looks like an ext4 inline-data boundary/state inconsistency triggered
> >> while writing to an ext4 image crafted by syzkaller. The later
> >> KASAN: slab-use-after-free in rwsem_down_write_slowpath() appears to be a
> >> secondary effect after the primary ext4 BUG, likely during teardown/unlink
> >> after the filesystem failure.
> >
> > Writing to a mounted image is not something that we consider a valid
> > threat model. If you can write to a mounted image, there are a
> > zillion different ways that you can creash the kernel, or you can
> > create a setuid shell, etc.
> >
> > The upstream syzkaller bot makes sure that CONFIG_BLK_DEV_WRITE_MOUNTED
> > is not defined to avoid syzkaller noise.
>
> CONFIG_BLK_DEV_WRITE_MOUNTED only blocks writing via the specific block
> device that is mounted. It doesn't block writing via other methods.
> If I recall correctly, its purpose was to prevent writing to the
> buffer cache used by the filesystem driver.
Correct. This a kind of corruption that's impossible to address only at fs
level.
> Changing block devices that are mounted is also reachable via USB.
> Yes, some distros may disable automount, but users who have stuff to
> get done will mount USB devices anyway. Telling users "don't do this"
> very rarely works in practice.
>
> I asked a distro maintainer about using libguestfs by default and
> they refused, citing poor performance. Unfortunately, there is no
> way at the OS level to distinguish "trusted device used for backups"
> and "untrusted USB stick".
Well, people *are* seriously looking into mounting hotpluggable devices with
FUSE (or other userspace means) - e.g. openSUSE has experimental packages
doing just that for a few months. Darrick Wong is also working on making
FUSE more performant so the plan is to eventually get there.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: [PATCH v11 00/15] Exposing case folding behavior
From: Jan Kara @ 2026-04-27 10:55 UTC (permalink / raw)
To: Chuck Lever
Cc: Al Viro, Christian Brauner, Jan Kara, linux-fsdevel, linux-ext4,
linux-xfs, linux-cifs, linux-nfs, linux-api, linux-f2fs-devel,
hirofumi, linkinjeon, sj1557.seo, yuezhang.mo,
almaz.alexandrovich, slava, glaubitz, frank.li, tytso,
adilger.kernel, cem, sfrench, pc, ronniesahlberg, sprasad,
trondmy, anna, jaegeuk, chao, hansg, senozhatsky, Chuck Lever,
Darrick J. Wong, Roland Mainz, Steve French
In-Reply-To: <20260424-case-sensitivity-v11-0-de5619beddaf@oracle.com>
On Fri 24-04-26 21:53:02, Chuck Lever wrote:
> Changes since v10:
> - cifs: Source case-handling flags from the server's cached
> FS_ATTRIBUTE_INFORMATION reply instead of the nocase mount
> option, with a nocase fallback when the reply is absent
> - Address findings from sashiko(gemini-3) and gpt-5.5:
> - nfs: Skip pathconf case bits on NFSv4 (set via FATTR4_CASE_*
> instead)
> - xfs: Hide FS_CASEFOLD_FL from the legacy flags view so
> chattr round-trips do not hit the setflags whitelist
> - ext4, f2fs: Drop redundant fileattr_get patches; the
> FS_CASEFOLD_FL translation in fileattr_fill_flags() already
> reports FS_XFLAG_CASEFOLD for casefolded directories
Err, how is this supposed to work? I wasn't able to find any code
transforming S_CASEFOLDED inode flag into FS_CASEFOLD_FL on fileattr_get
path. Sure, fileattr_fill_flags() takes care of setting FS_XFLAG_CASEFOLD
once FS_CASEFOLD_FL is set. What am I missing?
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: [PATCH v11 12/15] isofs: Implement fileattr_get for case sensitivity
From: Jan Kara @ 2026-04-27 10:44 UTC (permalink / raw)
To: Chuck Lever
Cc: Al Viro, Christian Brauner, Jan Kara, linux-fsdevel, linux-ext4,
linux-xfs, linux-cifs, linux-nfs, linux-api, linux-f2fs-devel,
hirofumi, linkinjeon, sj1557.seo, yuezhang.mo,
almaz.alexandrovich, slava, glaubitz, frank.li, tytso,
adilger.kernel, cem, sfrench, pc, ronniesahlberg, sprasad,
trondmy, anna, jaegeuk, chao, hansg, senozhatsky, Chuck Lever,
Roland Mainz
In-Reply-To: <20260424-case-sensitivity-v11-12-de5619beddaf@oracle.com>
On Fri 24-04-26 21:53:14, Chuck Lever wrote:
> From: Chuck Lever <chuck.lever@oracle.com>
>
> Upper layers such as NFSD need a way to query whether a
> filesystem handles filenames in a case-sensitive manner so
> they can provide correct semantics to remote clients. Without
> this information, NFS exports of ISO 9660 filesystems cannot
> advertise their filename case behavior.
>
> Implement isofs_fileattr_get() to report ISO 9660 case handling
> behavior via the FS_XFLAG_CASEFOLD flag. The 'check=r' (relaxed)
> mount option enables case-insensitive lookups, and this setting
> determines the value reported. By default, Joliet extensions
> operate in relaxed mode while plain ISO 9660 uses strict
> (case-sensitive) mode. All ISO 9660 variants are case-preserving,
> meaning filenames are stored exactly as they appear on the disc.
>
> Case handling is a superblock-wide property, so the callback
> must report the same value for every inode type. Regular files
> previously had no inode_operations; introduce
> isofs_file_inode_operations to carry the callback. Symlinks
> previously shared page_symlink_inode_operations; introduce
> isofs_symlink_inode_operations, which wires page_get_link
> alongside the callback, so that fileattr queries on a symlink
> reach the isofs implementation instead of returning
> -ENOIOCTLCMD. The flag is set in both fa->fsx_xflags and
> fa->flags so FS_IOC_FSGETXATTR and FS_IOC_GETFLAGS agree.
>
> Reviewed-by: Jan Kara <jack@suse.cz>
> Reviewed-by: Roland Mainz <roland.mainz@nrubsig.org>
> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
...
> @@ -281,6 +293,18 @@ const struct file_operations isofs_dir_operations =
> const struct inode_operations isofs_dir_inode_operations =
> {
> .lookup = isofs_lookup,
> + .fileattr_get = isofs_fileattr_get,
> +};
> +
> +const struct inode_operations isofs_file_inode_operations =
> +{
> + .fileattr_get = isofs_fileattr_get,
> +};
> +
> +const struct inode_operations isofs_symlink_inode_operations =
> +{
> + .get_link = page_get_link,
> + .fileattr_get = isofs_fileattr_get,
> };
Hum, I thought casefolding is a directory attribute. At least I don't see
a big point in reporting it for regular files or symlinks (and then why not
report it for device nodes or named pipes?). So why did you decide for this
change?
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* [PATCH v3 9/9] fstests: btrfs: test UUID consistency for clones with metadata_uuid
From: Anand Jain @ 2026-04-27 10:19 UTC (permalink / raw)
To: fstests
Cc: linux-btrfs, linux-ext4, linux-xfs, linux-f2fs, amir73il, zlang,
hch
In-Reply-To: <cover.1777281778.git.asj@kernel.org>
Btrfs uses the metadata_uuid superblock feature to change the on-disk UUID
without rewriting every block header. This patch adds a sanity check to
ensure UUID consistency when a filesystem with metadata_uuid enabled is
cloned.
Signed-off-by: Anand Jain <asj@kernel.org>
---
tests/btrfs/348 | 91 +++++++++++++++++++++++++++++++++++++++++++++
tests/btrfs/348.out | 19 ++++++++++
2 files changed, 110 insertions(+)
create mode 100644 tests/btrfs/348
create mode 100644 tests/btrfs/348.out
diff --git a/tests/btrfs/348 b/tests/btrfs/348
new file mode 100644
index 000000000000..cfa56fdb4a4a
--- /dev/null
+++ b/tests/btrfs/348
@@ -0,0 +1,91 @@
+#! /bin/bash
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (c) 2026 Anand Jain <asj@kernel.org>. All Rights Reserved.
+#
+# FS QA Test 348
+#
+# Verify that the cloned filesystem UUID remains consistent, even when the
+# `metadata_uuid` feature is enabled.
+#
+
+. ./common/preamble
+. ./common/filter
+
+_begin_fstest auto quick mount clone
+
+_require_test
+_require_loop
+
+_cleanup()
+{
+ cd /
+ rm -r -f $tmp.*
+ umount $mnt1 $mnt2 2>/dev/null
+ _loop_image_destroy "${devs[@]}" 2> /dev/null
+}
+
+filter_pool()
+{
+ sed -e "s|${devs[0]}|DEV1|g" -e "s|${mnt1}|MNT1|g" \
+ -e "s|${devs[1]}|DEV2|g" -e "s|${mnt2}|MNT2|g" | _filter_spaces
+}
+
+pre_clone_tune()
+{
+ local temp_mnt=$TEST_DIR/${seq}_mnt
+
+ _require_command "$BTRFS_TUNE_PROG" btrfstune
+ mkdir -p $temp_mnt
+ _mount ${devs[0]} $temp_mnt
+ $BTRFS_UTIL_PROG subvolume create $temp_mnt/sv1 &> /dev/null
+ _unmount $temp_mnt
+ rm -r -f $temp_mnt
+
+ $BTRFS_TUNE_PROG -m ${devs[0]}
+}
+
+print_info()
+{
+ local mntpt=$1
+ local tgt=$(findmnt -no SOURCE $mntpt)
+ local fsuuid=$(blkid -s UUID -o value $tgt)
+
+ echo "mntpt=$mntpt tgt=$tgt fsuuid=$fsuuid" >> $seqres.full
+ echo
+ findmnt -o SOURCE,TARGET,UUID "$tgt" | tail -n +2 | \
+ sed -e "s/${fsuuid}/FSUUID/g" | filter_pool
+ awk -v dev="$tgt" '$1 == dev { print $1, $2 }' /proc/self/mounts | \
+ filter_pool
+ df --all --output=source,target "$tgt" | tail -n +2 | filter_pool
+}
+
+devs=()
+_loop_image_create_clone devs pre_clone_tune
+mkdir -p $TEST_DIR/$seq
+mnt1=$TEST_DIR/$seq/mnt1
+mnt2=$TEST_DIR/$seq/mnt2
+mkdir -p $mnt1
+mkdir -p $mnt2
+
+_mount $(_common_dev_mount_options) $(_clone_mount_option) ${devs[0]} $mnt1 || \
+ _fail "Failed to mount dev1"
+_mount $(_common_dev_mount_options) $(_clone_mount_option) ${devs[1]} $mnt2 || \
+ _fail "Failed to mount dev2"
+
+print_info $mnt1
+print_info $mnt2
+
+echo
+echo "**** mount cycle ****"
+_unmount $mnt1
+_unmount $mnt2
+_mount $(_common_dev_mount_options) $(_clone_mount_option) ${devs[1]} $mnt2 || \
+ _fail "Failed to mount dev2"
+_mount $(_common_dev_mount_options) $(_clone_mount_option) ${devs[0]} $mnt1 || \
+ _fail "Failed to mount dev1"
+
+print_info $mnt1
+print_info $mnt2
+
+status=0
+exit
diff --git a/tests/btrfs/348.out b/tests/btrfs/348.out
new file mode 100644
index 000000000000..4b102e986246
--- /dev/null
+++ b/tests/btrfs/348.out
@@ -0,0 +1,19 @@
+QA output created by 348
+
+DEV1 MNT1 FSUUID
+DEV1 MNT1
+DEV1 MNT1
+
+DEV2 MNT2 FSUUID
+DEV2 MNT2
+DEV2 MNT2
+
+**** mount cycle ****
+
+DEV1 MNT1 FSUUID
+DEV1 MNT1
+DEV1 MNT1
+
+DEV2 MNT2 FSUUID
+DEV2 MNT2
+DEV2 MNT2
--
2.43.0
^ permalink raw reply related
* [PATCH v3 8/9] fstests: verify exportfs file handles on cloned filesystems
From: Anand Jain @ 2026-04-27 10:19 UTC (permalink / raw)
To: fstests
Cc: linux-btrfs, linux-ext4, linux-xfs, linux-f2fs, amir73il, zlang,
hch
In-Reply-To: <cover.1777281778.git.asj@kernel.org>
Ensure that exportfs can correctly decode file handles on a cloned
filesystem across a mount cycle, by file handles generated on a
cloned device remain valid after mount cycle.
Signed-off-by: Anand Jain <asj@kernel.org>
---
tests/generic/805 | 72 +++++++++++++++++++++++++++++++++++++++++++
tests/generic/805.out | 2 ++
2 files changed, 74 insertions(+)
create mode 100644 tests/generic/805
create mode 100644 tests/generic/805.out
diff --git a/tests/generic/805 b/tests/generic/805
new file mode 100644
index 000000000000..18c92205304c
--- /dev/null
+++ b/tests/generic/805
@@ -0,0 +1,72 @@
+#! /bin/bash
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (c) 2026 Anand Jain <asj@kernel.org>. All Rights Reserved.
+#
+# FS QA Test No. 805
+
+. ./common/preamble
+
+_begin_fstest auto quick exportfs clone
+
+_require_test
+_require_exportfs
+_require_loop
+_require_test_program "open_by_handle"
+
+_cleanup()
+{
+ cd /
+ rm -r -f $tmp.*
+ _unmount $mnt1 2>/dev/null
+ _unmount $mnt2 2>/dev/null
+ _loop_image_destroy "${devs[@]}" 2> /dev/null
+}
+
+# Create test dir and test files, encode file handles and store to tmp file
+create_test_files()
+{
+ rm -rf $testdir
+ mkdir -p $testdir
+ $here/src/open_by_handle -cwp -o $tmp.handles_file $testdir $NUMFILES
+}
+
+# Decode file handles loaded from tmp file
+test_file_handles()
+{
+ local opt=$1
+ local when=$2
+
+ echo test_file_handles after $when
+ $here/src/open_by_handle $opt -i $tmp.handles_file $mnt2 $NUMFILES
+}
+
+devs=()
+_loop_image_create_clone devs
+mkdir -p $TEST_DIR/$seq
+mnt1=$TEST_DIR/$seq/mnt1
+mnt2=$TEST_DIR/$seq/mnt2
+mkdir -p $mnt1
+mkdir -p $mnt2
+
+_mount $(_common_dev_mount_options) $(_clone_mount_option) ${devs[0]} $mnt1 || \
+ _fail "Failed to mount dev1"
+_mount $(_common_dev_mount_options) $(_clone_mount_option) ${devs[1]} $mnt2 || \
+ _fail "Failed to mount dev2"
+
+NUMFILES=1
+testdir=$mnt2/testdir
+
+# Decode file handles of files/dir after cycle mount
+create_test_files
+
+_unmount $mnt1
+_unmount $mnt2
+_mount $(_common_dev_mount_options) $(_clone_mount_option) ${devs[1]} $mnt2 || \
+ _fail "Failed to mount dev2"
+_mount $(_common_dev_mount_options) $(_clone_mount_option) ${devs[0]} $mnt1 || \
+ _fail "Failed to mount dev1"
+
+test_file_handles -rp "cycle mount"
+
+status=0
+exit
diff --git a/tests/generic/805.out b/tests/generic/805.out
new file mode 100644
index 000000000000..29b11ec77ffb
--- /dev/null
+++ b/tests/generic/805.out
@@ -0,0 +1,2 @@
+QA output created by 805
+test_file_handles after cycle mount
--
2.43.0
^ permalink raw reply related
* [PATCH v3 7/9] fstests: verify IMA isolation on cloned filesystems
From: Anand Jain @ 2026-04-27 10:19 UTC (permalink / raw)
To: fstests
Cc: linux-btrfs, linux-ext4, linux-xfs, linux-f2fs, amir73il, zlang,
hch
In-Reply-To: <cover.1777281778.git.asj@kernel.org>
Add testcase to verify IMA measurement isolation when multiple devices
share the same FSUUID.
Signed-off-by: Anand Jain <asj@kernel.org>
---
tests/generic/804 | 102 ++++++++++++++++++++++++++++++++++++++++++
tests/generic/804.out | 10 +++++
2 files changed, 112 insertions(+)
create mode 100644 tests/generic/804
create mode 100644 tests/generic/804.out
diff --git a/tests/generic/804 b/tests/generic/804
new file mode 100644
index 000000000000..5f5c04f97579
--- /dev/null
+++ b/tests/generic/804
@@ -0,0 +1,102 @@
+#! /bin/bash
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (c) 2026 Anand Jain <asj@kernel.org>. All Rights Reserved.
+#
+# FS QA Test 804
+# Verify IMA isolation on cloned filesystems:
+# . Mount two devices sharing the same FSUUID (cloned).
+# . Apply an IMA policy to measure files based on that FSUUID.
+# . Create unique files on each mount point to trigger measurements.
+# . Confirm the IMA log correctly attributes events to the respective mounts.
+
+. ./common/preamble
+. ./common/filter
+
+_begin_fstest auto quick clone
+
+_require_test
+_require_loop
+
+[ "$FSTYP" = "btrfs" ] && _fixed_by_kernel_commit xxxxxxxxxxxx \
+ "btrfs: use on-disk uuid for s_uuid in temp_fsid mounts"
+[ "$FSTYP" = "btrfs" ] && _fixed_by_kernel_commit xxxxxxxxxxxx \
+ "btrfs: derive f_fsid from on-disk fsuuid and dev_t"
+
+_cleanup()
+{
+ cd /
+ rm -r -f $tmp.*
+ _unmount $mnt1 2>/dev/null
+ _unmount $mnt2 2>/dev/null
+ _loop_image_destroy "${devs[@]}" 2> /dev/null
+}
+
+filter_pool()
+{
+ sed -e "s|${devs[0]}|DEV1|g" -e "s|$mnt1|MNT1|g" \
+ -e "s|${devs[1]}|DEV2|g" -e "s|$mnt2|MNT2|g" | _filter_spaces
+}
+
+do_ima()
+{
+ local ima_policy="/sys/kernel/security/ima/policy"
+ local ima_log="/sys/kernel/security/ima/ascii_runtime_measurements"
+ local fsuuid
+ local mnt=$1
+ local enable=$2
+
+ # Since the in-memory IMA audit log is only cleared upon reboot,
+ # use unique random filenames to avoid log collisions.
+ local foofile=$(mktemp --dry-run foobar_XXXXX)
+
+ echo $mnt $enable | filter_pool
+
+ [ -w "$ima_policy" ] || _notrun "IMA policy not writable"
+
+ fsuuid=$(blkid -s UUID -o value ${devs[0]})
+
+ # Load IMA policy to measure file access specifically for this
+ # filesystem UUID.
+ if [[ $enable -eq 1 ]]; then
+ echo "measure func=FILE_CHECK fsuuid=$fsuuid" > "$ima_policy" || \
+ _notrun "Policy rejected"
+ fi
+
+ # Create a file to trigger measurement and verify its entry in
+ # the IMA log.
+ echo "test_data" > $mnt/$foofile
+
+ # For $ima_log column entry please ref to
+ grep $foofile "$ima_log" | awk '{ print $5 }' | filter_pool | \
+ sed "s/$foofile/FOOBAR_FILE/"
+
+ echo "dbg: $mnt $fsuuid $foofile" >> $seqres.full
+ cat $ima_log | tail -1 >> $seqres.full
+ echo >> $seqres.full
+}
+
+devs=()
+_loop_image_create_clone devs
+mnt1=$TEST_DIR/$seq/mnt1
+mnt2=$TEST_DIR/$seq/mnt2
+mkdir -p $mnt1
+mkdir -p $mnt2
+
+_mount $(_common_dev_mount_options) $(_clone_mount_option) ${devs[0]} $mnt1 || \
+ _fail "Failed to mount dev1"
+_mount $(_common_dev_mount_options) $(_clone_mount_option) ${devs[1]} $mnt2 || \
+ _fail "Failed to mount dev2"
+
+do_ima $mnt1 1
+do_ima $mnt2 0
+
+# Btrfs uses in-memory dynamic temp_fsid
+echo mount cycle
+_unmount $mnt2
+_mount $mount_opts ${devs[1]} $mnt2 || _fail "Failed to mount dev2"
+
+do_ima $mnt1 0
+do_ima $mnt2 0
+
+status=0
+exit
diff --git a/tests/generic/804.out b/tests/generic/804.out
new file mode 100644
index 000000000000..9804181d6c17
--- /dev/null
+++ b/tests/generic/804.out
@@ -0,0 +1,10 @@
+QA output created by 804
+MNT1 1
+MNT1/FOOBAR_FILE
+MNT2 0
+MNT2/FOOBAR_FILE
+mount cycle
+MNT1 0
+MNT1/FOOBAR_FILE
+MNT2 0
+MNT2/FOOBAR_FILE
--
2.43.0
^ permalink raw reply related
* [PATCH v3 6/9] fstests: verify libblkid resolution of duplicate UUIDs
From: Anand Jain @ 2026-04-27 10:19 UTC (permalink / raw)
To: fstests
Cc: linux-btrfs, linux-ext4, linux-xfs, linux-f2fs, amir73il, zlang,
hch
In-Reply-To: <cover.1777281778.git.asj@kernel.org>
Verify how findmnt, df (libblkid) resolve device paths when multiple
block devices share the same FSUUID.
Signed-off-by: Anand Jain <asj@kernel.org>
---
tests/generic/803 | 75 +++++++++++++++++++++++++++++++++++++++++++
tests/generic/803.out | 19 +++++++++++
2 files changed, 94 insertions(+)
create mode 100644 tests/generic/803
create mode 100644 tests/generic/803.out
diff --git a/tests/generic/803 b/tests/generic/803
new file mode 100644
index 000000000000..1e0fbc768050
--- /dev/null
+++ b/tests/generic/803
@@ -0,0 +1,75 @@
+#! /bin/bash
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (c) 2026 Anand Jain <asj@kernel.org>. All Rights Reserved.
+#
+# FS QA Test 803
+# Verify how libblkid resolve devices when multiple devices sharing the
+# same FSUUID.
+
+. ./common/preamble
+. ./common/filter
+
+_begin_fstest auto quick mount clone
+
+_require_test
+_require_loop
+
+_cleanup()
+{
+ cd /
+ rm -r -f $tmp.*
+ umount $mnt1 $mnt2 2>/dev/null
+ _loop_image_destroy "${devs[@]}" 2> /dev/null
+}
+
+filter_pool()
+{
+ sed -e "s|${devs[0]}|DEV1|g" -e "s|${mnt1}|MNT1|g" \
+ -e "s|${devs[1]}|DEV2|g" -e "s|${mnt2}|MNT2|g" | _filter_spaces
+}
+
+print_info()
+{
+ local mntpt=$1
+ local tgt=$(findmnt -no SOURCE $mntpt)
+ local fsuuid=$(blkid -s UUID -o value $tgt)
+
+ echo "mntpt=$mntpt tgt=$tgt fsuuid=$fsuuid" >> $seqres.full
+ echo
+ findmnt -o SOURCE,TARGET,UUID "$tgt" | tail -n +2 | \
+ sed -e "s/${fsuuid}/FSUUID/g" | filter_pool
+ awk -v dev="$tgt" '$1 == dev { print $1, $2 }' /proc/self/mounts | \
+ filter_pool
+ df --all --output=source,target "$tgt" | tail -n +2 | filter_pool
+}
+
+devs=()
+_loop_image_create_clone devs
+mkdir -p $TEST_DIR/$seq
+mnt1=$TEST_DIR/$seq/mnt1
+mnt2=$TEST_DIR/$seq/mnt2
+mkdir -p $mnt1
+mkdir -p $mnt2
+
+_mount $(_common_dev_mount_options) $(_clone_mount_option) ${devs[0]} $mnt1 || \
+ _fail "Failed to mount dev1"
+_mount $(_common_dev_mount_options) $(_clone_mount_option) ${devs[1]} $mnt2 || \
+ _fail "Failed to mount dev2"
+
+print_info $mnt1
+print_info $mnt2
+
+echo
+echo "**** mount cycle ****"
+_unmount $mnt1
+_unmount $mnt2
+_mount $(_common_dev_mount_options) $(_clone_mount_option) ${devs[1]} $mnt2 || \
+ _fail "Failed to mount dev2"
+_mount $(_common_dev_mount_options) $(_clone_mount_option) ${devs[0]} $mnt1 || \
+ _fail "Failed to mount dev1"
+
+print_info $mnt1
+print_info $mnt2
+
+status=0
+exit
diff --git a/tests/generic/803.out b/tests/generic/803.out
new file mode 100644
index 000000000000..20a1cb36a213
--- /dev/null
+++ b/tests/generic/803.out
@@ -0,0 +1,19 @@
+QA output created by 803
+
+DEV1 MNT1 FSUUID
+DEV1 MNT1
+DEV1 MNT1
+
+DEV2 MNT2 FSUUID
+DEV2 MNT2
+DEV2 MNT2
+
+**** mount cycle ****
+
+DEV1 MNT1 FSUUID
+DEV1 MNT1
+DEV1 MNT1
+
+DEV2 MNT2 FSUUID
+DEV2 MNT2
+DEV2 MNT2
--
2.43.0
^ permalink raw reply related
* [PATCH v3 5/9] fstests: verify f_fsid for cloned filesystems
From: Anand Jain @ 2026-04-27 10:19 UTC (permalink / raw)
To: fstests
Cc: linux-btrfs, linux-ext4, linux-xfs, linux-f2fs, amir73il, zlang,
hch
In-Reply-To: <cover.1777281778.git.asj@kernel.org>
Verify that the cloned filesystem provides an f_fsid that is persistent
across mount cycles, yet unique from the original filesystem's f_fsid.
Signed-off-by: Anand Jain <asj@kernel.org>
---
tests/generic/802 | 61 +++++++++++++++++++++++++++++++++++++++++++
tests/generic/802.out | 7 +++++
2 files changed, 68 insertions(+)
create mode 100644 tests/generic/802
create mode 100644 tests/generic/802.out
diff --git a/tests/generic/802 b/tests/generic/802
new file mode 100644
index 000000000000..83e75dcd0d78
--- /dev/null
+++ b/tests/generic/802
@@ -0,0 +1,61 @@
+#! /bin/bash
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (c) 2026 Anand Jain <asj@kernel.org>. All Rights Reserved.
+#
+# FS QA Test 802
+# Verify f_fsid and s_uuid of cloned filesystems across mount cycle.
+
+. ./common/preamble
+
+_begin_fstest auto quick mount clone
+
+_require_test
+_require_loop
+
+[ "$FSTYP" = "btrfs" ] && _fixed_by_kernel_commit xxxxxxxxxxxx \
+ "btrfs: use on-disk uuid for s_uuid in temp_fsid mounts"
+[ "$FSTYP" = "btrfs" ] && _fixed_by_kernel_commit xxxxxxxxxxxx \
+ "btrfs: derive f_fsid from on-disk fsuuid and dev_t"
+
+_cleanup()
+{
+ cd /
+ rm -r -f $tmp.*
+ umount $mnt1 $mnt2 2>/dev/null
+ _loop_image_destroy "${devs[@]}" 2> /dev/null
+}
+
+devs=()
+_loop_image_create_clone devs
+mkdir -p $TEST_DIR/$seq
+mnt1=$TEST_DIR/$seq/mnt1
+mnt2=$TEST_DIR/$seq/mnt2
+mkdir -p $mnt1
+mkdir -p $mnt2
+
+_mount $(_common_dev_mount_options) $(_clone_mount_option) ${devs[0]} $mnt1 || \
+ _fail "Failed to mount dev1"
+_mount $(_common_dev_mount_options) $(_clone_mount_option) ${devs[1]} $mnt2 || \
+ _fail "Failed to mount dev2"
+
+fsid_scratch=$(stat -f -c "%i" $mnt1)
+fsid_clone=$(stat -f -c "%i" $mnt2)
+
+echo "**** fsid initially ****"
+echo $fsid_scratch | sed -e "s/$fsid_scratch/FSID_SCRATCH/g"
+echo $fsid_clone | sed -e "s/$fsid_clone/FSID_CLONE/g"
+
+# Make sure fsid still match across a mount cycle, also reverse the order.
+echo "**** fsid after mount cycle ****"
+_unmount $mnt1
+_unmount $mnt2
+_mount $(_common_dev_mount_options) $(_clone_mount_option) ${devs[1]} $mnt2 || \
+ _fail "Failed to mount dev2"
+_mount $(_common_dev_mount_options) $(_clone_mount_option) ${devs[0]} $mnt1 || \
+ _fail "Failed to mount dev1"
+
+stat -f -c "%i" $mnt1 | sed -e "s/$fsid_scratch/FSID_SCRATCH/g"
+stat -f -c "%i" $mnt2 | sed -e "s/$fsid_clone/FSID_CLONE/g"
+
+status=0
+exit
diff --git a/tests/generic/802.out b/tests/generic/802.out
new file mode 100644
index 000000000000..d1e008f122bb
--- /dev/null
+++ b/tests/generic/802.out
@@ -0,0 +1,7 @@
+QA output created by 802
+**** fsid initially ****
+FSID_SCRATCH
+FSID_CLONE
+**** fsid after mount cycle ****
+FSID_SCRATCH
+FSID_CLONE
--
2.43.0
^ permalink raw reply related
* [PATCH v3 4/9] fstests: verify fanotify isolation on cloned filesystems
From: Anand Jain @ 2026-04-27 10:19 UTC (permalink / raw)
To: fstests
Cc: linux-btrfs, linux-ext4, linux-xfs, linux-f2fs, amir73il, zlang,
hch
In-Reply-To: <cover.1777281778.git.asj@kernel.org>
Verify that fanotify events are correctly routed to the appropriate
watcher when cloned filesystems are mounted.
Helps verify kernel's event notification distinguishes between devices
sharing the same FSID/UUID.
Signed-off-by: Anand Jain <asj@kernel.org>
---
common/config | 1 +
tests/generic/801 | 115 ++++++++++++++++++++++++++++++++++++++++++
tests/generic/801.out | 7 +++
3 files changed, 123 insertions(+)
create mode 100644 tests/generic/801
create mode 100644 tests/generic/801.out
diff --git a/common/config b/common/config
index 605a57947a40..1588bdcb1aa1 100644
--- a/common/config
+++ b/common/config
@@ -243,6 +243,7 @@ export PARTED_PROG="$(type -P parted)"
export XFS_PROPERTY_PROG="$(type -P xfs_property)"
export FSCRYPTCTL_PROG="$(type -P fscryptctl)"
export INOTIFYWAIT_PROG="$(type -P inotifywait)"
+export FSNOTIFYWAIT_PROG="$(type -P fsnotifywait)"
# udev wait functions.
#
diff --git a/tests/generic/801 b/tests/generic/801
new file mode 100644
index 000000000000..3f64e4de2206
--- /dev/null
+++ b/tests/generic/801
@@ -0,0 +1,115 @@
+#! /bin/bash
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (c) 2026 Anand Jain <asj@kernel.org>. All Rights Reserved.
+#
+# FS QA Test 801
+# Verify fanotify FID functionality on cloned filesystems by setting up
+# watchers and making sure notifications are in the correct logs files.
+
+. ./common/preamble
+
+_begin_fstest auto quick mount clone
+
+_require_test
+_require_loop
+_require_command "$FSNOTIFYWAIT_PROG" fsnotifywait
+
+[ "$FSTYP" = "ext4" ] && _fixed_by_kernel_commit xxxxxxxxxxxx \
+ "ext4: derive f_fsid from block device to avoid collisions"
+
+_cleanup()
+{
+ cd /
+ [[ -n $pid1 ]] && { kill -TERM "$pid1" 2> /dev/null; wait $pid1; }
+ [[ -n $pid2 ]] && { kill -TERM "$pid2" 2> /dev/null; wait $pid2; }
+ umount $mnt1 $mnt2 2>/dev/null
+ _loop_image_destroy "${devs[@]}" 2> /dev/null
+ rm -r -f $tmp.*
+}
+
+monitor_fanotify()
+{
+ local mmnt=$1
+ exec stdbuf -oL $FSNOTIFYWAIT_PROG -m -F -S -e create "$mmnt" 2>&1
+}
+
+fsid_to_fid_parts()
+{
+ local fsid=$1
+ # Pad to 16 hex chars (64-bit), then split into two 32-bit halves
+ local padded=$(printf '%016x' "0x${fsid}")
+ local hi=$(printf '%x' "0x${padded:0:8}") # strips leading zeros
+ local lo=$(printf '%x' "0x${padded:8:8}") # strips leading zeros
+ echo "${hi}.${lo}"
+}
+
+devs=()
+_loop_image_create_clone devs
+mkdir -p $TEST_DIR/$seq
+mnt1=$TEST_DIR/$seq/mnt1
+mnt2=$TEST_DIR/$seq/mnt2
+mkdir -p $mnt1
+mkdir -p $mnt2
+
+_mount $(_common_dev_mount_options) $(_clone_mount_option) ${devs[0]} $mnt1 || \
+ _fail "Failed to mount dev1"
+_mount $(_common_dev_mount_options) $(_clone_mount_option) ${devs[1]} $mnt2 || \
+ _fail "Failed to mount dev2"
+
+fsid1=$(stat -f -c "%i" $mnt1)
+fsid2=$(stat -f -c "%i" $mnt2)
+
+[[ "$fsid1" == "$fsid2" ]] && \
+ _notrun "Require clone filesystem with unique f_fsid"
+
+log1=$tmp.fanotify1
+log2=$tmp.fanotify2
+
+pid1=""
+pid2=""
+echo "Setup FID fanotify watchers on both mnt1 and mnt2"
+( monitor_fanotify "$mnt1" > "$log1" ) &
+pid1=$!
+( monitor_fanotify "$mnt2" > "$log2" ) &
+pid2=$!
+sleep 2
+
+echo "Trigger file creation on mnt1"
+touch $mnt1/file_on_mnt1
+sync
+sleep 1
+
+echo "Trigger file creation on mnt2"
+touch $mnt2/file_on_mnt2
+sync
+sleep 1
+
+echo "Verify fsid in the fanotify"
+kill $pid1 $pid2
+wait $pid1 $pid2 2>/dev/null
+pid1=""
+pid2=""
+
+e_fsid1=$(fsid_to_fid_parts "$fsid1")
+e_fsid2=$(fsid_to_fid_parts "$fsid2")
+
+echo $fsid1 $e_fsid1 $fsid2 $e_fsid2 >> $seqres.full
+cat $log1 >> $seqres.full
+cat $log2 >> $seqres.full
+
+if grep -qF "$e_fsid1" "$log1" && ! grep -qF "$e_fsid2" "$log1"; then
+ echo "SUCCESS: mnt1 events found"
+else
+ [ ! -s "$log1" ] && echo " - mnt1 received no events."
+ grep -qF "$e_fsid2" "$log1" && echo " - mnt1 received event from mnt2."
+fi
+
+if grep -qF "$e_fsid2" "$log2" && ! grep -qF "$e_fsid1" "$log2"; then
+ echo "SUCCESS: mnt2 events found"
+else
+ [ ! -s "$log2" ] && echo " - mnt2 received no events."
+ grep -qF "$e_fsid1" "$log2" && echo " - mnt2 received event from mnt1."
+fi
+
+status=0
+exit
diff --git a/tests/generic/801.out b/tests/generic/801.out
new file mode 100644
index 000000000000..d7b318d9f27c
--- /dev/null
+++ b/tests/generic/801.out
@@ -0,0 +1,7 @@
+QA output created by 801
+Setup FID fanotify watchers on both mnt1 and mnt2
+Trigger file creation on mnt1
+Trigger file creation on mnt2
+Verify fsid in the fanotify
+SUCCESS: mnt1 events found
+SUCCESS: mnt2 events found
--
2.43.0
^ permalink raw reply related
* [PATCH v3 3/9] fstests: add test for inotify isolation on cloned devices
From: Anand Jain @ 2026-04-27 10:19 UTC (permalink / raw)
To: fstests
Cc: linux-btrfs, linux-ext4, linux-xfs, linux-f2fs, amir73il, zlang,
hch
In-Reply-To: <cover.1777281778.git.asj@kernel.org>
Add a new test, to verify that the kernel correctly differentiates between
two block devices sharing the same FSID/UUID.
Signed-off-by: Anand Jain <asj@kernel.org>
---
common/config | 1 +
tests/generic/800 | 88 +++++++++++++++++++++++++++++++++++++++++++
tests/generic/800.out | 7 ++++
3 files changed, 96 insertions(+)
create mode 100644 tests/generic/800
create mode 100644 tests/generic/800.out
diff --git a/common/config b/common/config
index 4fd4c2c8af11..605a57947a40 100644
--- a/common/config
+++ b/common/config
@@ -242,6 +242,7 @@ export BTRFS_MAP_LOGICAL_PROG=$(type -P btrfs-map-logical)
export PARTED_PROG="$(type -P parted)"
export XFS_PROPERTY_PROG="$(type -P xfs_property)"
export FSCRYPTCTL_PROG="$(type -P fscryptctl)"
+export INOTIFYWAIT_PROG="$(type -P inotifywait)"
# udev wait functions.
#
diff --git a/tests/generic/800 b/tests/generic/800
new file mode 100644
index 000000000000..16bc1159a2e1
--- /dev/null
+++ b/tests/generic/800
@@ -0,0 +1,88 @@
+#! /bin/bash
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (c) 2026 Anand Jain <asj@kernel.org>. All Rights Reserved.
+#
+# FS QA Test 800
+#
+# Verify if the kernel or userspace becomes confused when two block devices
+# share the same fid/fsid/uuid. Create inotify on both original and cloned
+# filesystem. Monitor the notification in the respective logs.
+
+. ./common/preamble
+
+_begin_fstest auto quick mount clone
+
+_require_test
+_require_loop
+_require_command "$INOTIFYWAIT_PROG" inotifywait
+
+_cleanup()
+{
+ cd /
+ [[ -n $pid1 ]] && { kill -TERM "$pid1" 2> /dev/null; wait $pid1; }
+ [[ -n $pid2 ]] && { kill -TERM "$pid2" 2> /dev/null; wait $pid2; }
+ rm -r -f $tmp.*
+ _unmount $mnt1 2>/dev/null
+ _unmount $mnt2 2>/dev/null
+ _loop_image_destroy "${devs[@]}" 2> /dev/null
+}
+
+devs=()
+_loop_image_create_clone devs
+mkdir -p $TEST_DIR/$seq
+mnt1=$TEST_DIR/$seq/mnt1
+mnt2=$TEST_DIR/$seq/mnt2
+mkdir -p $mnt1
+mkdir -p $mnt2
+
+_mount $(_common_dev_mount_options) $(_clone_mount_option) ${devs[0]} $mnt1 || \
+ _fail "Failed to mount dev1"
+_mount $(_common_dev_mount_options) $(_clone_mount_option) ${devs[1]} $mnt2 || \
+ _fail "Failed to mount dev2"
+
+log1=$tmp.inotify1
+log2=$tmp.inotify2
+
+pid1=""
+pid2=""
+echo "Setup inotify watchers on both mnt1 and mnt2"
+$INOTIFYWAIT_PROG -m -e create --format '%f' $mnt1 > $log1 2>&1 &
+pid1=$!
+$INOTIFYWAIT_PROG -m -e create --format '%f' $mnt2 > $log2 2>&1 &
+pid2=$!
+sleep 2
+
+echo "Trigger file creation on mnt1"
+touch $mnt1/file_on_mnt1
+sync
+sleep 1
+
+echo "Trigger file creation on mnt2"
+touch $mnt2/file_on_mnt2
+sync
+sleep 1
+
+echo "Verify inotify isolation"
+kill $pid1 $pid2
+wait $pid1 $pid2 2>/dev/null
+pid1=""
+pid2=""
+
+if grep -q "file_on_mnt1" $log1 && ! grep -q "file_on_mnt2" $log1; then
+ echo "SUCCESS: mnt1 events isolated."
+else
+ echo "FAIL: mnt1 inotify confusion!"
+ [ ! -s $log1 ] && echo " - mnt1 received no events."
+ grep -q "file_on_mnt2" $log1 && echo " - mnt1 received event from mnt2."
+fi
+
+if grep -q "file_on_mnt2" $log2 && ! grep -q "file_on_mnt1" $log2; then
+ echo "SUCCESS: mnt2 events isolated."
+else
+ echo "FAIL: mnt2 inotify confusion!"
+ [ ! -s $log2 ] && echo " - mnt2 received no events."
+ grep -q "file_on_mnt1" $log2 && echo " - mnt2 received event from mnt1."
+fi
+
+status=0
+exit
diff --git a/tests/generic/800.out b/tests/generic/800.out
new file mode 100644
index 000000000000..b10842a31210
--- /dev/null
+++ b/tests/generic/800.out
@@ -0,0 +1,7 @@
+QA output created by 800
+Setup inotify watchers on both mnt1 and mnt2
+Trigger file creation on mnt1
+Trigger file creation on mnt2
+Verify inotify isolation
+SUCCESS: mnt1 events isolated.
+SUCCESS: mnt2 events isolated.
--
2.43.0
^ permalink raw reply related
* [PATCH v3 2/9] fstests: add _clone_mount_option() helper
From: Anand Jain @ 2026-04-27 10:19 UTC (permalink / raw)
To: fstests
Cc: linux-btrfs, linux-ext4, linux-xfs, linux-f2fs, amir73il, zlang,
hch
In-Reply-To: <cover.1777281778.git.asj@kernel.org>
Adds _clone_mount_option() helper function to handle filesystem-specific
requirements for mounting cloned devices. Abstract the need for -o nouuid
on XFS.
Signed-off-by: Anand Jain <asj@kernel.org>
---
common/rc | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/common/rc b/common/rc
index 0e7b7eb1d98f..2d28e174f605 100644
--- a/common/rc
+++ b/common/rc
@@ -397,6 +397,20 @@ _scratch_mount_options()
$SCRATCH_DEV $SCRATCH_MNT
}
+_clone_mount_option()
+{
+ local mount_opts=""
+
+ case "$FSTYP" in
+ xfs)
+ mount_opts="-o nouuid"
+ ;;
+ *)
+ esac
+
+ echo $mount_opts
+}
+
_supports_filetype()
{
local dir=$1
--
2.43.0
^ permalink raw reply related
* [PATCH v3 1/9] fstests: add _loop_image_create_clone() helper
From: Anand Jain @ 2026-04-27 10:19 UTC (permalink / raw)
To: fstests
Cc: linux-btrfs, linux-ext4, linux-xfs, linux-f2fs, amir73il, zlang,
hch
In-Reply-To: <cover.1777281778.git.asj@kernel.org>
Introduce _loop_image_create_clone() and _loop_image_destroy() to mkfs an
image file and clone it to another image file, and attach a loop device to
them. And its destroy part.
Signed-off-by: Anand Jain <asj@kernel.org>
---
common/rc | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/common/rc b/common/rc
index 9632b211b58f..0e7b7eb1d98f 100644
--- a/common/rc
+++ b/common/rc
@@ -1503,6 +1503,50 @@ _scratch_resvblks()
esac
}
+_loop_image_create_clone()
+{
+ local -n _ret=$1
+ local pre_clone_tune_func=$2
+ local img_file=$TEST_DIR/${seq}.img
+ local img_file_clone=$TEST_DIR/${seq}_clone.img
+ local size=$(_small_fs_size_mb 128) # Smallest possible
+ local loop_devs
+
+ size=$((size * 1024 * 1024))
+ $XFS_IO_PROG -f -c "truncate $size" $img_file
+
+ loop_devs=$(_create_loop_device $img_file)
+ _ret=($loop_devs)
+
+ case $FSTYP in
+ xfs)
+ _mkfs_dev "-s size=4096" $img_file
+ ;;
+ btrfs)
+ _mkfs_dev $img_file
+ ;;
+ *)
+ _mkfs_dev $img_file
+ ;;
+ esac
+
+ ($pre_clone_tune_func)
+
+ cp $img_file $img_file_clone
+
+ loop_devs="$loop_devs $(_create_loop_device $img_file_clone)"
+
+ _ret=($loop_devs)
+}
+
+_loop_image_destroy()
+{
+ for d in "$@"; do
+ local f=$(losetup --noheadings --output BACK-FILE $d)
+ _destroy_loop_device "$d"
+ [ -n "$f" ] && rm -f "$f"
+ done
+}
# Repair scratch filesystem. Returns 0 if the FS is good to go (either no
# errors found or errors were fixed) and nonzero otherwise; also spits out
--
2.43.0
^ permalink raw reply related
* [PATCH v3 0/9] fstests: add test coverage for cloned filesystem ids
From: Anand Jain @ 2026-04-27 10:19 UTC (permalink / raw)
To: fstests
Cc: linux-btrfs, linux-ext4, linux-xfs, linux-f2fs, amir73il, zlang,
hch
v3:
Dropped the -o nouuid mount option.
Added a Btrfs test case to verify clones of filesystems using the
metadata_uuid superblock feature.
Updated _loop_image_create_clone() to handle necessary pre-clone
filesystem tuning.
v2:
https://lore.kernel.org/fstests/cover.1774090817.git.asj@kernel.org
Anand Jain (9):
fstests: add _loop_image_create_clone() helper
fstests: add _clone_mount_option() helper
fstests: add test for inotify isolation on cloned devices
fstests: verify fanotify isolation on cloned filesystems
fstests: verify f_fsid for cloned filesystems
fstests: verify libblkid resolution of duplicate UUIDs
fstests: verify IMA isolation on cloned filesystems
fstests: verify exportfs file handles on cloned filesystems
fstests: btrfs: test UUID consistency for clones with metadata_uuid
common/config | 2 +
common/rc | 58 +++++++++++++++++++++
tests/btrfs/348 | 91 +++++++++++++++++++++++++++++++++
tests/btrfs/348.out | 19 +++++++
tests/generic/800 | 88 ++++++++++++++++++++++++++++++++
tests/generic/800.out | 7 +++
tests/generic/801 | 115 ++++++++++++++++++++++++++++++++++++++++++
tests/generic/801.out | 7 +++
tests/generic/802 | 61 ++++++++++++++++++++++
tests/generic/802.out | 7 +++
tests/generic/803 | 75 +++++++++++++++++++++++++++
tests/generic/803.out | 19 +++++++
tests/generic/804 | 102 +++++++++++++++++++++++++++++++++++++
tests/generic/804.out | 10 ++++
tests/generic/805 | 72 ++++++++++++++++++++++++++
tests/generic/805.out | 2 +
16 files changed, 735 insertions(+)
create mode 100644 tests/btrfs/348
create mode 100644 tests/btrfs/348.out
create mode 100644 tests/generic/800
create mode 100644 tests/generic/800.out
create mode 100644 tests/generic/801
create mode 100644 tests/generic/801.out
create mode 100644 tests/generic/802
create mode 100644 tests/generic/802.out
create mode 100644 tests/generic/803
create mode 100644 tests/generic/803.out
create mode 100644 tests/generic/804
create mode 100644 tests/generic/804.out
create mode 100644 tests/generic/805
create mode 100644 tests/generic/805.out
--
2.43.0
^ permalink raw reply
* Re: [PATCH v2 3/3] ext4: derive f_fsid from block device to avoid collisions
From: Anand Jain @ 2026-04-27 10:16 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Theodore Tso, Darrick J. Wong, linux-ext4, linux-btrfs, linux-xfs,
Anand Jain, dsterba
In-Reply-To: <aempTb5TyKG0vPL0@infradead.org>
On 23/4/26 13:08, Christoph Hellwig wrote:
> On Wed, Apr 22, 2026 at 07:39:57PM +0800, Anand Jain wrote:
>>> No, T10 does not actually mandate unique identifiers, NVMe does, but the
>>> implementations are often totally broken.
>>
>> Right. Newer SPC-3 (and above) compliant devices must support
>> the Inquiry CDB EVPD flag and provide page 0x83 for identification,
>> which is what we typically use for multipathing.
>
> But there is no requirement for it to contain something useful.
>
>> These are globally unique. And, we can overlook legacy
>> drives, as they've probably been past their EOSL for a while now.
>
> We have absolutely no useful identifiers for most USB devices.
> NVMe devices have broken identifiers all the time as well.
>
> So no, you can't.
Agreed. I have dropped the plan to rely on hardware identifiers;
the lack of consistency in USB/NVMe firmware makes them a
non-starter for a stable identifier.
The updated patch set, excluding the ext4 changes, has been
submitted to the mailing list. Fstests test case updated as well.
Thanks, Anand
^ permalink raw reply
* Re: [PATCH] ext4: fix LOGFLUSH shutdown ordering to allow ordered-mode data writeback
From: Jan Kara @ 2026-04-27 9:53 UTC (permalink / raw)
To: Zhang Yi
Cc: linux-ext4, linux-fsdevel, linux-kernel, tytso, adilger.kernel,
libaokun, jack, ojaswin, ritesh.list, yi.zhang, yizhang089,
yangerkun, yukuai
In-Reply-To: <20260424104201.1930823-1-yi.zhang@huaweicloud.com>
On Fri 24-04-26 18:42:01, Zhang Yi wrote:
> From: Zhang Yi <yi.zhang@huawei.com>
>
> In EXT4_GOING_FLAGS_LOGFLUSH mode, the EXT4_FLAGS_SHUTDOWN flag was set
> before calling ext4_force_commit(). This caused ordered-mode data
> writeback (triggered by journal commit) to fail with -EIO, since
> ext4_do_writepages() checks for the shutdown flag. The journal would
> then be aborted prematurely before the commit could succeed.
>
> Fix this by calling ext4_force_commit() first, then setting the
> shutdown flag, so that pending data can be written back correctly.
>
> Note that moving ext4_force_commit() before setting the shutdown flag
> creates a small window in which new writes may occur and generate new
> journal transactions. When the journal is subsequently aborted, the
> new transactions will not be able to write to disk. This is intentional
> because LOGFLUSH's semantics are to flush pre-existing journal entries
> before shutdown, not to guarantee atomicity for writes that race with
> the ioctl.
>
> Fixes: 783d94854499 ("ext4: add EXT4_IOC_GOINGDOWN ioctl")
> Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
Looks good. Feel free to add:
Reviewed-by: Jan Kara <jack@suse.cz>
Honza
> ---
> This fix addresses my new generic/970 test, which fails during the file
> size verification after shutdown and remount.
>
> https://lore.kernel.org/fstests/20260424092228.1396658-1-yi.zhang@huaweicloud.com/
>
> fs/ext4/ioctl.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
> index 1d0c3d4bdf47..110e3fb194ec 100644
> --- a/fs/ext4/ioctl.c
> +++ b/fs/ext4/ioctl.c
> @@ -830,11 +830,17 @@ int ext4_force_shutdown(struct super_block *sb, u32 flags)
> bdev_thaw(sb->s_bdev);
> break;
> case EXT4_GOING_FLAGS_LOGFLUSH:
> + /*
> + * Call ext4_force_commit() before setting EXT4_FLAGS_SHUTDOWN.
> + * This is because in data=ordered mode, journal commit
> + * triggers data writeback which fails if shutdown is already
> + * set, causing the journal to be aborted prematurely before
> + * the commit succeeds.
> + */
> + (void) ext4_force_commit(sb);
> set_bit(EXT4_FLAGS_SHUTDOWN, &sbi->s_ext4_flags);
> - if (sbi->s_journal && !is_journal_aborted(sbi->s_journal)) {
> - (void) ext4_force_commit(sb);
> + if (sbi->s_journal && !is_journal_aborted(sbi->s_journal))
> jbd2_journal_abort(sbi->s_journal, -ESHUTDOWN);
> - }
> break;
> case EXT4_GOING_FLAGS_NOLOGFLUSH:
> set_bit(EXT4_FLAGS_SHUTDOWN, &sbi->s_ext4_flags);
> --
> 2.52.0
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: [PATCH v3 v3 2/2] ext4: allow clearing mballoc stats through mb_stats
From: liubaolin @ 2026-04-27 1:29 UTC (permalink / raw)
To: Baokun Li, Theodore Tso
Cc: adilger.kernel, ojaswin, ritesh.list, yi.zhang, linux-ext4,
linux-kernel, wangguanyu, Baolin Liu, Andreas Dilger
In-Reply-To: <5eaa521b-28b0-4c2a-a33d-57d1449f125e@linux.alibaba.com>
Dear Baokun,
Thank you and Ted for your review and suggestions.
I will incorporate your suggestions and submit the v4 patch as soon
as possible.
Thanks,
Baolin
在 2026/4/24 17:34, Baokun Li 写道:
>
> On 2026/4/24 16:09, liubaolin wrote:
>>
>>
>> 在 2026/4/24 0:19, Theodore Tso 写道:
>>> On Wed, Apr 22, 2026 at 09:50:25AM +0800, Baolin Liu wrote:
>>>> From: Baolin Liu <liubaolin@kylinos.cn>
>>>>
>>>> Make /proc/fs/ext4/<dev>/mb_stats writable and clear the runtime
>>>> mballoc statistics when 0 is written.
>>>
>>> At the moment to enable mb_stats the system administrator needs to
>>> write "1" to /sys/fs/ext4/<dev>/mb_stats, and writing "0" to the sysfs
>>> file will pauce the statistics colleciton (but not clear the
>>> statistics). Adding a way to clear the statistics by writing to the
>>> procfs file might be confusing to users.
>>>
>>> So.... as a suggestion, if you're adding to the ability to write to
>>> /proc/fs/.../mb_stats, what if we make things work by
>>>
>>> * Write 1 to /proc/fs/.../mb_stats to enable statistics collection
>>> * Write 0 to /proc/fs/.../mb_stats to disable statistics collection
>>> * Write -1 to /proc/fs/.../mb_stats to clear statistics counters
>>>
>>> And then deprecate the /sys/fs/.../mb_stats variable (but we probably
>>> won't be able to remove it for at least a year or two).
>>>
>>> - Ted
>> Dear Ted, Baokun,
>> Thank you for your review and suggestions.
>> Since you mentioned that /sys/fs/.../mb_stats cannot be deleted in
>> the short term,
>> I plan to modify and submit a v4 patch according to the following
>> strategy.
>>
>> 1. Change `/proc/fs/.../mb_stats` to read-write mode.
>> * Read `/proc/fs/.../mb_stats` to show statistics counters.
>> * Write 0 to `/proc/fs/.../mb_stats` to disable statistics
>> collection.
>> * Write 1 to `/proc/fs/.../mb_stats` to enable statistics collection.
>> * Write 2 to `/proc/fs/.../mb_stats` to clear statistics counters.
>>
>> 2. Do not delete the `/sys/fs/.../mb_stats` node for now; implement
>> the same write control logic.
>> * Write 0 to `/sys/fs/.../mb_stats` to disable statistics collection.
>> * Write 1 to `/sys/fs/.../mb_stats` to enable statistics collection.
>> * Write 2 to `/sys/fs/.../mb_stats` to clear statistics counters.
>>
>> Delete `/sys/fs/.../mb_stats` later when it is possible to delete it.
>>
>> 3. Modify the relevant documentation for `mb_stats`.
>> Documentation/ABI/testing/sysfs-fs-ext4
>> Documentation/admin-guide/ext4.rst
>> Documentation/filesystems/proc.rst
>>
>> Compared to your suggestion, I recommend using the value 2 for the
>> clear operation because s_mb_stats is an unsigned int variable, and
>> using -1 requires changing the variable type.
>> I suggest avoiding changing the s_mb_stats variable type unless
>> absolutely necessary.
>>
>> Do you think this modification is appropriate?
>> If there are no problems, I will start modifying the code and
>> submit the v4 patch as soon as possible.
>
> For the clear command, we only handle it without storing it, so s_mb_stats
> remains unchanged and still stores only 0 and non-zero values to represent
> disabled and enabled, respectively. Otherwise, you will have to deal with
> a large number of s_mb_stats checks
>
> That means the /sys/fs/.../mb_stats interface does not need to support
> clearing, but it might make sense to add a deprecation warning there.
>
> Then in `/proc/fs/.../mb_stats`, writing 0 or a positive number passes
> it to s_mb_stats, writing -1 performs a reset, and other negative values
> return -EINVAL.
>
>
> Cheers,
> Baokun
>
^ permalink raw reply
* Re: [PATCH v3 v3 2/2] ext4: allow clearing mballoc stats through mb_stats
From: liubaolin @ 2026-04-27 1:24 UTC (permalink / raw)
To: Theodore Tso
Cc: libaokun, adilger.kernel, ojaswin, ritesh.list, yi.zhang,
linux-ext4, linux-kernel, wangguanyu, Baolin Liu, Andreas Dilger
In-Reply-To: <20260424120702.GD11127@macsyma-wired.lan>
Dear Ted,
Thank you and Baokun for your review and suggestions.
I will incorporate your suggestions and submit the v4 patch as soon
as possible.
Thanks,
Baolin
在 2026/4/24 20:07, Theodore Tso 写道:
> On Fri, Apr 24, 2026 at 04:09:31PM +0800, liubaolin wrote:
>>
>> 2. Do not delete the `/sys/fs/.../mb_stats` node for now; implement the
>> same write control logic.
>> * Write 0 to `/sys/fs/.../mb_stats` to disable statistics collection.
>> * Write 1 to `/sys/fs/.../mb_stats` to enable statistics collection.
>> * Write 2 to `/sys/fs/.../mb_stats` to clear statistics counters.
>
> We could do that, but note that currently writing to
> /sys/fs/.../mb_stats just sets an unsigned integer in
> EXT4(sb)->s_mb_stats. There is no ext4-specific function that runs
> when /sys/fs/.../mb_stats is updated.
>
> So either you have to add some check in fs/ext4/mballoc.c which gets
> called every single time a block allocation happens --- and consider
> the race condition where two CPU's are checking s_mb_stats at the same
> time, and the desireability of adding a spinlock that would need to be
> taken every single time a block allocation happens ---- or you have
> add an ext4-specific function in fs/ext4/sysfs.c.
>
>> Compared to your suggestion, I recommend using the value 2 for the clear
>> operation because s_mb_stats is an unsigned int variable, and using -1
>> requires changing the variable type.
>
> Well, since you have introduced an ext4-specific function which gets
> called when writing to the procfs file, that function can clear the
> statistics counter when -1 is written to the file --- and then set
> s_mbi_stats to 1.
>
> Cheers,
>
> - Ted
^ permalink raw reply
* [syzbot] [ext4?] BUG: sleeping function called from invalid context in jbd2_journal_commit_transaction
From: syzbot @ 2026-04-26 21:18 UTC (permalink / raw)
To: jack, linux-ext4, linux-kernel, syzkaller-bugs, tytso
Hello,
syzbot found the following issue on:
HEAD commit: 6596a02b2078 Merge tag 'drm-next-2026-04-22' of https://gi..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=120d3702580000
kernel config: https://syzkaller.appspot.com/x/.config?x=80b28e8d6ef9384a
dashboard link: https://syzkaller.appspot.com/bug?extid=06294fd562f060379c91
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/5b2b3122db47/disk-6596a02b.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/7ee12b37f6e5/vmlinux-6596a02b.xz
kernel image: https://storage.googleapis.com/syzbot-assets/aca25073993c/bzImage-6596a02b.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+06294fd562f060379c91@syzkaller.appspotmail.com
BUG: sleeping function ca[ 92.150581][ T5155] BUG: sleeping function called from invalid context at fs/jbd2/commit.c:1071
in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 5155, name: jbd2/sda1-8
preempt_count: 0, expected: 0
RCU nest depth: 2, expected: 1
3 locks held by jbd2/sda1-8/5155:
#0: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:300 [inline]
#0: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:838 [inline]
#0: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: __rt_spin_lock kernel/locking/spinlock_rt.c:50 [inline]
#0: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: rt_spin_lock+0x1e0/0x400 kernel/locking/spinlock_rt.c:57
#1: ffff888036ea4920 (&journal->j_list_lock){+.+.}-{3:3}, at: spin_lock include/linux/spinlock_rt.h:45 [inline]
#1: ffff888036ea4920 (&journal->j_list_lock){+.+.}-{3:3}, at: jbd2_journal_commit_transaction+0x3ad1/0x5b20 fs/jbd2/commit.c:993
#2: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:300 [inline]
#2: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:838 [inline]
#2: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: __rt_spin_lock kernel/locking/spinlock_rt.c:50 [inline]
#2: ffffffff8dfc80c0 (rcu_read_lock){....}-{1:3}, at: rt_spin_lock+0x1e0/0x400 kernel/locking/spinlock_rt.c:57
CPU: 0 UID: 0 PID: 5155 Comm: jbd2/sda1-8 Not tainted syzkaller #0 PREEMPT_{RT,(full)}
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/18/2026
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
__might_resched+0x329/0x480 kernel/sched/core.c:9162
jbd2_journal_commit_transaction+0x3f59/0x5b20 fs/jbd2/commit.c:1071
kjournald2+0x3e0/0x760 fs/jbd2/journal.c:201
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
------------[ cut here ]------------
Voluntary context switch within RCU read-side critical section!
WARNING: kernel/rcu/tree_plugin.h:332 at rcu_note_context_switch+0xcac/0xf40 kernel/rcu/tree_plugin.h:332, CPU#0: jbd2/sda1-8/5155
Modules linked in:
CPU: 0 UID: 0 PID: 5155 Comm: jbd2/sda1-8 Tainted: G W syzkaller #0 PREEMPT_{RT,(full)}
Tainted: [W]=WARN
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/18/2026
RIP: 0010:rcu_note_context_switch+0xcac/0xf40 kernel/rcu/tree_plugin.h:332
Code: 00 41 c6 45 00 00 48 8b 3d a1 20 e1 0d 48 81 c4 b8 00 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d e9 bb 5f ff ff 48 8d 3d a4 e2 e4 0d <67> 48 0f b9 3a e9 1b f4 ff ff 90 0f 0b 90 45 84 e4 0f 84 ea f3 ff
RSP: 0018:ffffc90010177930 EFLAGS: 00010002
RAX: 0000000000000000 RBX: ffff888036ec5c40 RCX: 0000000080000002
RDX: 0000000000000000 RSI: ffffffff8ba74040 RDI: ffffffff8f8f3dd0
RBP: dffffc0000000000 R08: ffffffff8f8bcef7 R09: 1ffffffff1f179de
R10: dffffc0000000000 R11: fffffbfff1f179df R12: 0000000000000000
R13: dffffc0000000000 R14: ffff8880b883c800 R15: ffff888036ec6104
FS: 0000000000000000(0000) GS:ffff8881260fb000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055557df50340 CR3: 0000000011b24000 CR4: 00000000003526f0
Call Trace:
<TASK>
__schedule+0x291/0x54c0 kernel/sched/core.c:7043
__schedule_loop kernel/sched/core.c:7267 [inline]
schedule+0x164/0x360 kernel/sched/core.c:7282
kjournald2+0x410/0x760 fs/jbd2/journal.c:230
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
----------------
Code disassembly (best guess):
0: 00 41 c6 add %al,-0x3a(%rcx)
3: 45 00 00 add %r8b,(%r8)
6: 48 8b 3d a1 20 e1 0d mov 0xde120a1(%rip),%rdi # 0xde120ae
d: 48 81 c4 b8 00 00 00 add $0xb8,%rsp
14: 5b pop %rbx
15: 41 5c pop %r12
17: 41 5d pop %r13
19: 41 5e pop %r14
1b: 41 5f pop %r15
1d: 5d pop %rbp
1e: e9 bb 5f ff ff jmp 0xffff5fde
23: 48 8d 3d a4 e2 e4 0d lea 0xde4e2a4(%rip),%rdi # 0xde4e2ce
* 2a: 67 48 0f b9 3a ud1 (%edx),%rdi <-- trapping instruction
2f: e9 1b f4 ff ff jmp 0xfffff44f
34: 90 nop
35: 0f 0b ud2
37: 90 nop
38: 45 84 e4 test %r12b,%r12b
3b: 0f .byte 0xf
3c: 84 ea test %ch,%dl
3e: f3 repz
3f: ff .byte 0xff
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox