linux-kernel - 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: <20250729144526.GB2672049@frogsfrogsfrogs>
Date: Tue, 29 Jul 2025 07:45:26 -0700
From: "Darrick J. Wong" <djwong@...nel.org>
To: Ojaswin Mujoo <ojaswin@...ux.ibm.com>
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 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

> > 
> > > 
> > > 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
> > 
>