All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zorro Lang <zlang@kernel.org>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: qsa@qualys.com, fstests <fstests@vger.kernel.org>,
	 xfs <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH v2] generic: regression test for refluxfs fixes
Date: Tue, 25 Aug 2026 04:18:43 +0800	[thread overview]
Message-ID: <aoyhsTq7abQSSDnQ@zlang-mailbox> (raw)
In-Reply-To: <20260824191513.GS839663@frogsfrogsfrogs>

On Mon, Aug 24, 2026 at 12:15:13PM -0700, Darrick J. Wong wrote:
> On Tue, Aug 25, 2026 at 02:15:31AM +0800, Zorro Lang wrote:
> > On Mon, Aug 24, 2026 at 09:45:16AM -0700, Darrick J. Wong wrote:
> > > On Mon, Aug 24, 2026 at 10:05:25PM +0800, Zorro Lang wrote:
> > > > On Fri, Aug 21, 2026 at 04:51:55PM -0700, Darrick J. Wong wrote:
> > > > > From: Darrick J. Wong <djwong@kernel.org>
> > > > > 
> > > > > Regression test for refluxfs as found by Qualys.
> > > > > 
> > > > > Reported-by: qsa@qualys.com
> > > > > Co-developed-by: qsa@qualys.com
> > > > > Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> > > > > ---
> > > > > v2: add co-author credits
> > > > > ---
> > > > 
> > > > Hi Darrick,
> > > > 
> > > > I just gave this patch a try on linux v7.2+ which contains the commit
> > > > 2f4acd0fcd862e, but the test still fails as shown below on both xfs
> > > > and btrfs. Did I miss anything?
> > > > 
> > > > root@bogon:~/git/linux# git tag --contains 2f4acd0fcd862e
> > > > v7.2
> > > > v7.2-rc4
> > > > v7.2-rc5
> > > > v7.2-rc6
> > > > v7.2-rc7
> > > > 
> > > > root@bogon:~/git/xfstests-dev# ./check generic/1956
> > > > FSTYP         -- xfs (debug)
> > > > PLATFORM      -- Linux/x86_64 bogon 7.2.0-mainline+ #3 SMP PREEMPT_DYNAMIC Mon Aug 24 20:34:26 CST 2026
> > > > MKFS_OPTIONS  -- -f /dev/sdc1
> > > > MOUNT_OPTIONS -- -o context=system_u:object_r:root_t:s0 /dev/sdc1 /mnt/scratch
> > > > 
> > > > generic/1956       - output mismatch (see /root/git/xfstests-dev/results//generic/1956.out.bad)
> > > >     --- tests/generic/1956.out  2026-08-24 14:19:18.790104900 +0800
> > > >     +++ /root/git/xfstests-dev/results//generic/1956.out.bad    2026-08-24 21:41:51.884222239 +0800
> > > >     @@ -1,2 +1,2 @@
> > > >      QA output created by 1956
> > > >     -corruption not observed
> > > >     +unknown outcome 126
> > > 
> > > 126 is probably su trying to communicate that it couldn't actually run
> > > refluxfs.  _require_test_program should have _notrun if the binary
> > > didn't build, so ... I don't know what's going on here.  Does
> > > $seqres.full have anything interesting to say?  Or does su'ing to fsgqa
> > > not work?
> > 
> > Wow, you reminded me! The /root/ directory doesn't has 'x' permission for others,
> > so this $qa_user can't run /root/git/xfstests-dev/src/refluxfs . My bad, now
> > it works :)
> 
> Oh.
> 
> > > 
> > > (FWIW it works fine on my system even with large block size)
> > 
> > It's fine with large block size? In my review comments below, I questioned
> > the hardcoded "BLK=4096". While it might not fail on an XFS with a non-4k
> > block size, it probably won't trigger the bug either on an unfixed kernel,
> > right?
> 
> It should on a 1k fsblock filesystem the kernel will just mash
> four blocks.  Though I guess for a 64k fsblock filesystem it'll fall
> back to pagecache writes and fail to trigger it.
> 
> I dunno.  Changing BLK to 65536 seems to make it reproduce reliably here
> on every fsblock size between 1k and 64k so I'll make that modification
> and resend it.

I just reproduced it on XFS with a 1024 block size. Apologies for the delay,
the reproduce rate on my side was quite low, so I ran it in a `while true`
loop and finally triggered the bug (I'm still waiting for the 65536 blocksize
xfs testing result).

Thanks,
Zorro

> 
> --D
> 
> > Thanks,
> > Zorro
> > 
> > > 
> > > --D
> > > 
> > > >     ...
> > > >     (Run 'diff -u /root/git/xfstests-dev/tests/generic/1956.out /root/git/xfstests-dev/results//generic/1956.out.bad'  to see the entire diff)
> > > > 
> > > > HINT: You _MAY_ be missing kernel fix:
> > > >       2f4acd0fcd862e xfs: resample the data fork mapping after cycling ILOCK
> > > > 
> > > > Ran: generic/1956
> > > > Failures: generic/1956
> > > > Failed 1 of 1 tests
> > > > 
> > > > root@bogon:~/git/xfstests-dev# ./check generic/1956
> > > > FSTYP         -- btrfs
> > > > PLATFORM      -- Linux/x86_64 bogon 7.2.0-mainline+ #3 SMP PREEMPT_DYNAMIC Mon Aug 24 20:34:26 CST 2026
> > > > MKFS_OPTIONS  -- /dev/sdc1
> > > > MOUNT_OPTIONS -- -o context=system_u:object_r:root_t:s0 /dev/sdc1 /mnt/scratch
> > > > 
> > > > generic/1956       - output mismatch (see /root/git/xfstests-dev/results//generic/1956.out.bad)
> > > >     --- tests/generic/1956.out  2026-08-24 14:19:18.790104900 +0800
> > > >     +++ /root/git/xfstests-dev/results//generic/1956.out.bad    2026-08-24 21:44:35.654443414 +0800
> > > >     @@ -1,2 +1,2 @@
> > > >      QA output created by 1956
> > > >     -corruption not observed
> > > >     +unknown outcome 126
> > > >     ...
> > > >     (Run 'diff -u /root/git/xfstests-dev/tests/generic/1956.out /root/git/xfstests-dev/results//generic/1956.out.bad'  to see the entire diff)
> > > > Ran: generic/1956
> > > > Failures: generic/1956
> > > > Failed 1 of 1 tests
> > > > 
> > > > 
> > > > >  .gitignore             |    1 
> > > > >  src/Makefile           |    2 
> > > > >  src/refluxfs.c         |  461 ++++++++++++++++++++++++++++++++++++++++++++++++
> > > > >  tests/generic/1956     |   58 ++++++
> > > > >  tests/generic/1956.out |    2 
> > > > >  5 files changed, 523 insertions(+), 1 deletion(-)
> > > > >  create mode 100644 src/refluxfs.c
> > > > >  create mode 100755 tests/generic/1956
> > > > >  create mode 100644 tests/generic/1956.out
> > > > >
> > > > 
> > > > [snip]
> > > > 
> > > > > +#ifndef FICLONE
> > > > > +#define FICLONE _IOW(0x94, 9, int)
> > > > > +#endif
> > > > > +#ifndef XFS_SUPER_MAGIC
> > > > > +#define XFS_SUPER_MAGIC 0x58465342
> > > > > +#endif
> > > > > +
> > > > > +#define BLK 4096
> > > > 
> > > > This's a hard code, what if the fs blocksize or pagesize isn't 4096?
> > > > 
> > > > > +
> > > > > +/* ---- configuration (overridable via CLI) --------------------------------- */
> > > > > +static const char *target_path   = "/etc/passwd";
> > > > > +static const char *clone_dir     = "/var/tmp";
> > > > > +static int         nr_writers    = 32;
> > > > > +static int         nr_pressure   = 8;
> > > > > +static int         budget_s      = 300;
> > > > > +
> > > > 
> > > > [snip]
> > > > 
> > > > > +
> > > > > +#if 0
> > > > > +static int is_xfs(const char *p)
> > > > > +{
> > > > > +    struct statfs s;
> > > > > +    if (statfs(p, &s)) return -1;
> > > > > +    return s.f_type == XFS_SUPER_MAGIC;
> > > > > +}
> > > > > +#endif
> > > > 
> > > > If this's useless, how about remove them?
> > > > 
> > > > > +
> > > > > +/* FIEMAP: is the target's first extent already shared (refcount > 1)?
> > > > > + * If so the race can never see refcount==1. */
> > > > > +static int target_first_extent_shared(void)
> > > > > +{
> > > > 
> > > > [snip]
> > > > 
> > > > > +#if 0
> > > > > +    /* 2. target on XFS */
> > > > > +    int x = is_xfs(target_path);
> > > > > +    if (x < 0) die(1, "statfs target", NULL);
> > > > > +    if (!x) {
> > > > > +        BAD("target is not on XFS (f_type != XFS_SUPER_MAGIC).");
> > > > > +        INFO("RefluXFS only affects XFS with reflink=1 (mkfs.xfs default since");
> > > > > +        INFO("xfsprogs 5.1.0; backported by Red Hat for RHEL 8 GA).  Default root");
> > > > > +        INFO("fs on RHEL/CentOS/Rocky/Alma/OL/CloudLinux 8+, Fedora Server 31+,");
> > > > > +        INFO("Amazon Linux 2023.");
> > > > > +        exit(1);
> > > > > +    }
> > > > > +    OK("target is on XFS");
> > > > > +#endif
> > > > 
> > > > Same
> > > > 
> > > > > +
> > > > > +    /* 3. clone_dir on the same superblock */
> > > > > +    if (access(clone_dir, W_OK)) die(1, "clone dir not writable",
> > > > > +        "Need a writable directory on the SAME XFS filesystem as the target.");
> > > > 
> > > > [snip]
> > > > 
> > > > > +static void *pressure(void *arg)
> > > > > +{
> > > > > +    char p[600];
> > > > > +    snprintf(p, sizeof p, "%s/press.%d", workdir, (int)(intptr_t)arg);
> > > > > +    int fd = open(p, O_RDWR|O_CREAT|O_TRUNC, 0600);
> > > > > +    if (fd < 0) return NULL;
> > > > > +    char b = 0;
> > > > > +    while (!atomic_load(&stop)) {
> > > > > +        /* return values irrelevant -- goal is XFS log traffic, not the data */
> > > > > +        (void)!pwrite(fd, &b, 1, 0);
> > > > > +        (void)!ftruncate(fd, BLK);
> > > > > +        fdatasync(fd);
> > > > > +        (void)!ftruncate(fd, 0);
> > > > 
> > > > As this's a generic test case, the pressure() works for XFS CIL, does it work
> > > > for other filesystems?
> > > > 
> > > > Thanks,
> > > > Zorro
> > > 
> > 
> 

  reply	other threads:[~2026-08-24 20:18 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-21 23:51 [PATCH v2] generic: regression test for refluxfs fixes Darrick J. Wong
2026-08-24  4:48 ` Christoph Hellwig
2026-08-24 14:05 ` Zorro Lang
2026-08-24 16:45   ` Darrick J. Wong
2026-08-24 18:15     ` Zorro Lang
2026-08-24 19:15       ` Darrick J. Wong
2026-08-24 20:18         ` Zorro Lang [this message]
2026-09-24 18:30           ` Darrick J. Wong
2026-09-28 12:55             ` Zorro Lang
2026-09-28 15:32               ` Darrick J. Wong
2026-08-24 17:40   ` Darrick J. Wong

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=aoyhsTq7abQSSDnQ@zlang-mailbox \
    --to=zlang@kernel.org \
    --cc=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=qsa@qualys.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.