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: <2ae4bb04-fbf7-4a53-b498-ea6361cdab3e@oracle.com>
Date: Mon, 28 Jul 2025 10:09:47 +0100
From: John Garry <john.g.garry@...cle.com>
To: Ojaswin Mujoo <ojaswin@...ux.ibm.com>
Cc: Zorro Lang <zlang@...hat.com>, fstests@...r.kernel.org,
        Ritesh Harjani <ritesh.list@...il.com>, djwong@...nel.org,
        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 28/07/2025 07:43, Ojaswin Mujoo wrote:
>>> What do you mean by not safe?
>> Multiple threads issuing atomic writes may trample over one another.
>>
>> It is due to the steps used to issue an atomic write in xfs by software
>> method. Here we do 3x steps:
>> a. allocate blocks for out-of-place write
>> b. do write in those blocks
>> c. atomically update extent mapping.
>>
>> In this, threads wanting to atomic write to the same address will use the
>> new blocks and can trample over one another before we atomically update the
>> mapping.
> So iiuc, w/ software fallback, a thread atomically writing to a range
> will use a new block A. Another parallel thread trying to atomically
> write to the same range will also use A, and there is no serialization
> b/w the 2 so A could end up with a mix of data from both threads.

right

> 
> If this is true, aren't we violating the atomic guarantees. Nothing
> prevents the userspace from doing overlapping parallel atomic writes and
> it is kernels duty to error out if the write could get torn.

Correct, but simply userspace should not do this. Direct I/O 
applications are responsible for ordering.

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.

Thanks,
John