linux-ext4 - Re: [PATCH v3 05/13] generic/1226: Add atomic write test using fio crc check verifier

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aIrun9794W0eZA8d@li-dc0c254c-257c-11b2-a85c-98b6c1322444.ibm.com>
Date: Thu, 31 Jul 2025 09:48:39 +0530
From: Ojaswin Mujoo <ojaswin@...ux.ibm.com>
To: "Darrick J. Wong" <djwong@...nel.org>
Cc: John Garry <john.g.garry@...cle.com>, Zorro Lang <zlang@...hat.com>,
        fstests@...r.kernel.org, Ritesh Harjani <ritesh.list@...il.com>,
        tytso@....edu, linux-xfs@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-ext4@...r.kernel.org
Subject: Re: [PATCH v3 05/13] generic/1226: Add atomic write test using fio
 crc check verifier

On Tue, Jul 29, 2025 at 07:45:26AM -0700, Darrick J. Wong wrote:
> On Tue, Jul 29, 2025 at 11:41:39AM +0530, Ojaswin Mujoo wrote:
> > On Mon, Jul 28, 2025 at 03:00:40PM +0100, John Garry wrote:
> > > On 28/07/2025 14:35, Ojaswin Mujoo wrote:
> > > > > We guarantee that the write is committed all-or-nothing, but do rely on
> > > > > userspace not issuing racing atomic writes or racing regular writes.
> > > > > 
> > > > > I can easily change this, as I mentioned, but I am not convinced that it is
> > > > > a must.
> > > > Purely from a design point of view, I feel we are breaking atomicity and
> > > > hence we should serialize or just stop userspace from doing this (which
> > > > is a bit extreme).
> > > 
> > > If you check the man page description of RWF_ATOMIC, it does not mention
> > > serialization. The user should conclude that usual direct IO rules apply,
> > > i.e. userspace is responsible for serializing.
> > 
> > My mental model of serialization in context of atomic writes is that if
> > user does 64k atomic write A followed by a parallel overlapping 64kb
> > atomic write B then the user might see complete A or complete B (we
> > don't guarantee) but not a mix of A and B.
> 
> Heh, here comes that feature naming confusing again.  This is my
> definition:
> 
> RWF_ATOMIC means the system won't introduce new tearing when persisting
> file writes.  The application is allowed to introduce tearing by writing
> to overlapping ranges at the same time.  The system does not isolate
> overlapping reads from writes.
> 
> --D

Hey Darrick, John,

So seems like my expectations of RWF_ATOMIC were a bit misplaced. I
understand now that we don't really guarantee much when there are
overlapping parallel writes going on. Even 2 overlapping RWF_ATOMIC
writes can get torn. Seems like there are some edge cases where this
might happen with hardware atomic writes as well.

In that sense, if this fio test is doing overlapped atomic io and
expecting them to be untorn, I don't think that's the correct way to
test it since that is beyond what RWF_ATOMIC guarantees. 

I'll try to check if we can modify the tests to write on non-overlapping
ranges in a file.

Thanks and sorry for the confusion :)
Ojaswin

> 
> > > 
> > > > 
> > > > I know userspace should ideally not do overwriting atomic writes but if
> > > > it is something we are allowing (which we do) then it is
> > > > kernel's responsibility to ensure atomicity. Sure we can penalize them
> > > > by serializing the writes but not by tearing it.
> > > > 
> > > > With that reasoning, I don't think the test should accomodate for this
> > > > particular scenario.
> > > 
> > > I can send a patch to the community for xfs (to provide serialization), like
> > > I showed earlier, to get opinion.
> > 
> > Thanks, that would be great.
> > 
> > Regards,
> > John
> > > 
> > > Thanks,
> > > John
> > > 
> >