lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aOJrNHcQPD7bgnfB@li-dc0c254c-257c-11b2-a85c-98b6c1322444.ibm.com>
Date: Sun, 5 Oct 2025 18:27:24 +0530
From: Ojaswin Mujoo <ojaswin@...ux.ibm.com>
To: Zorro Lang <zlang@...hat.com>
Cc: fstests@...r.kernel.org, Ritesh Harjani <ritesh.list@...il.com>,
        djwong@...nel.org, john.g.garry@...cle.com, tytso@....edu,
        linux-xfs@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-ext4@...r.kernel.org
Subject: Re: [PATCH v7 04/12] ltp/fsx.c: Add atomic writes support to fsx

On Sat, Oct 04, 2025 at 01:19:32AM +0800, Zorro Lang wrote:
> On Thu, Oct 02, 2025 at 11:26:45PM +0530, Ojaswin Mujoo wrote:
> > On Sun, Sep 28, 2025 at 09:19:24PM +0800, Zorro Lang wrote:
> > > On Fri, Sep 19, 2025 at 12:17:57PM +0530, Ojaswin Mujoo wrote:
> > > > Implement atomic write support to help fuzz atomic writes
> > > > with fsx.
> > > > 
> > > > Suggested-by: Ritesh Harjani (IBM) <ritesh.list@...il.com>
> > > > Reviewed-by: Darrick J. Wong <djwong@...nel.org>
> > > > Reviewed-by: John Garry <john.g.garry@...cle.com>
> > > > Signed-off-by: Ojaswin Mujoo <ojaswin@...ux.ibm.com>
> > > > ---
> > > 
> > > Hmm... this patch causes more regular fsx test cases fail on old kernel,
> > > (e.g. g/760, g/617, g/263 ...) except set "FSX_AVOID=-a". Is there a way
> > > to disable "atomic write" automatically if it's not supported by current
> > > system?
> > 
> > Hi Zorro, 
> > Sorry for being late, I've been on vacation this week.
> > 
> > Yes so by design we should be automatically disabling atomic writes when
> > they are not supported by the stack but seems like the issue is that
> > when we do disable it we print some extra messages to stdout/err which
> > show up in the xfstests output causing failure.
> > 
> > I can think of 2 ways around this:
> > 
> > 1. Don't print anything and just silently drop atomic writes if stack
> > doesn't support them.
> > 
> > 2. Make atomic writes as a default off instead of default on feature but
> > his loses a bit of coverage as existing tests wont get atomic write
> > testing free of cost any more.
> 
> Hi Ojaswin,
> 
> Please have a nice vacation :)
> 
> It's not the "extra messages" cause failure, those "quiet" failures can be fixed
> by:

Oh okay got it.

> 
> diff --git a/ltp/fsx.c b/ltp/fsx.c
> index bdb87ca90..0a035b37b 100644
> --- a/ltp/fsx.c
> +++ b/ltp/fsx.c
> @@ -1847,8 +1847,9 @@ int test_atomic_writes(void) {
>         struct statx stx;
>  
>         if (o_direct != O_DIRECT) {
> -               fprintf(stderr, "main: atomic writes need O_DIRECT (-Z), "
> -                               "disabling!\n");
> +               if (!quiet)
> +                       fprintf(stderr, "main: atomic writes need O_DIRECT (-Z), "
> +                                       "disabling!\n");
>                 return 0;
>         }
>  
> @@ -1867,8 +1868,9 @@ int test_atomic_writes(void) {
>                 return 1;
>         }
>  
> -       fprintf(stderr, "main: IO Stack does not support "
> -                       "atomic writes, disabling!\n");
> +       if (!quiet)
> +               fprintf(stderr, "main: IO Stack does not support "
> +                               "atomic writes, disabling!\n");
>         return 0;
>  }

> 
> But I hit more read or write failures e.g. [1], this failure can't be
> reproduced with FSX_AVOID=-a. Is it a atomic write bug or an unexpected
> test failure?
> 
> Thanks,
> Zorro
> 

<...>

> +244(244 mod 256): SKIPPED (no operation)
> +245(245 mod 256): FALLOC   0x695c5 thru 0x6a2e6	(0xd21 bytes) INTERIOR
> +246(246 mod 256): MAPWRITE 0x5ac00 thru 0x5b185	(0x586 bytes)
> +247(247 mod 256): WRITE    0x31200 thru 0x313ff	(0x200 bytes)
> +248(248 mod 256): SKIPPED (no operation)
> +249(249 mod 256): TRUNCATE DOWN	from 0x78242 to 0xf200	******WWWW
> +250(250 mod 256): FALLOC   0x65000 thru 0x66f26	(0x1f26 bytes) PAST_EOF
> +251(251 mod 256): WRITE    0x45400 thru 0x467ff	(0x1400 bytes) HOLE	***WWWW
> +252(252 mod 256): SKIPPED (no operation)
> +253(253 mod 256): SKIPPED (no operation)
> +254(254 mod 256): MAPWRITE 0x4be00 thru 0x4daee	(0x1cef bytes)
> +255(255 mod 256): MAPREAD  0xc000 thru 0xcae9	(0xaea bytes)
> +256(  0 mod 256): READ     0x3e000 thru 0x3efff	(0x1000 bytes)
> +257(  1 mod 256): SKIPPED (no operation)
> +258(  2 mod 256): INSERT 0x45000 thru 0x45fff	(0x1000 bytes)
> +259(  3 mod 256): ZERO     0x1d7d5 thru 0x1f399	(0x1bc5 bytes)	******ZZZZ
> +260(  4 mod 256): TRUNCATE DOWN	from 0x4eaef to 0x11200	******WWWW
> +261(  5 mod 256): WRITE    0x43000 thru 0x43fff	(0x1000 bytes) HOLE	***WWWW
> +262(  6 mod 256): WRITE    0x2200 thru 0x31ff	(0x1000 bytes)
> +263(  7 mod 256): WRITE    0x15000 thru 0x15fff	(0x1000 bytes)
> +264(  8 mod 256): WRITE    0x2e400 thru 0x2e7ff	(0x400 bytes)
> +265(  9 mod 256): COPY 0xd000 thru 0xdfff	(0x1000 bytes) to 0x1d800 thru 0x1e7ff	******EEEE
> +266( 10 mod 256): CLONE 0x2a000 thru 0x2afff	(0x1000 bytes) to 0x21000 thru 0x21fff
> +267( 11 mod 256): MAPREAD  0x31000 thru 0x31d0a	(0xd0b bytes)
> +268( 12 mod 256): SKIPPED (no operation)
> +269( 13 mod 256): WRITE    0x25000 thru 0x25fff	(0x1000 bytes)
> +270( 14 mod 256): SKIPPED (no operation)
> +271( 15 mod 256): MAPREAD  0x30000 thru 0x30577	(0x578 bytes)
> +272( 16 mod 256): PUNCH    0x1a267 thru 0x1c093	(0x1e2d bytes)
> +273( 17 mod 256): MAPREAD  0x1f000 thru 0x1f9c9	(0x9ca bytes)
> +274( 18 mod 256): WRITE    0x40800 thru 0x40dff	(0x600 bytes)
> +275( 19 mod 256): SKIPPED (no operation)
> +276( 20 mod 256): MAPWRITE 0x20600 thru 0x22115	(0x1b16 bytes)
> +277( 21 mod 256): MAPWRITE 0x3d000 thru 0x3ee5a	(0x1e5b bytes)
> +278( 22 mod 256): WRITE    0x2ee00 thru 0x2efff	(0x200 bytes)
> +279( 23 mod 256): WRITE    0x76200 thru 0x769ff	(0x800 bytes) HOLE
> +280( 24 mod 256): SKIPPED (no operation)
> +281( 25 mod 256): SKIPPED (no operation)
> +282( 26 mod 256): MAPREAD  0xa000 thru 0xa5e7	(0x5e8 bytes)
> +283( 27 mod 256): SKIPPED (no operation)
> +284( 28 mod 256): SKIPPED (no operation)
> +285( 29 mod 256): SKIPPED (no operation)
> +286( 30 mod 256): SKIPPED (no operation)
> +287( 31 mod 256): COLLAPSE 0x11000 thru 0x11fff	(0x1000 bytes)
> +288( 32 mod 256): COPY 0x5d000 thru 0x5dfff	(0x1000 bytes) to 0x4ca00 thru 0x4d9ff
> +289( 33 mod 256): TRUNCATE DOWN	from 0x75a00 to 0x1e400
> +290( 34 mod 256): MAPREAD  0x1c000 thru 0x1d802	(0x1803 bytes)	***RRRR***
> +Log of operations saved to "/mnt/xfstests/test/junk.fsxops"; replay with --replay-ops
> +Correct content saved for comparison
> +(maybe hexdump "/mnt/xfstests/test/junk" vs "/mnt/xfstests/test/junk.fsxgood")
> 
> Thanks,
> Zorro

Hi Zorro, just to confirm is this on an older kernel that doesnt support
RWF_ATOMIC or on a kernle that does support it.

Regards,
ojaswin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ