linux-kernel - Re: [PATCH v4 04/11] generic: 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: <4572fcd8-6364-4827-af9b-d11728c39c78@oracle.com>
Date: Thu, 21 Aug 2025 10:24:58 +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 v4 04/11] generic: Add atomic write test using fio crc
 check verifier

On 21/08/2025 09:42, Ojaswin Mujoo wrote:
> On Wed, Aug 13, 2025 at 02:39:40PM +0100, John Garry wrote:
>> On 10/08/2025 14:41, Ojaswin Mujoo wrote:
>>> This adds atomic write test using fio based on it's crc check verifier.
>>> fio adds a crc for each data block. If the underlying device supports
>>> atomic write then it is guaranteed that we will never have a mix data from
>>> two threads writing on the same physical block.
>>>
>>> Avoid doing overlapping parallel atomic writes because it might give
>>> unexpected results. Use offset_increment=, size= fio options to achieve
>>> this behavior.
>>>
>> You are not really describing what the test does.
>>
>> In the first paragraph, you state what fio verify function does and then
>> describe what RWF_ATOMIC means when we only use HW support, i.e. serialises.
>> In the second you mention that we guarantee no inter-thread overlapping
>> writes.
> Got it John, I will add better commit messages for the fio tests.
>>  From a glance at the code below, in this test each thread writes to a
>> separate part of the file and then verifies no crc corruption. But even with
>> atomic=0, I would expect no corruption here.
> Right, this is mostly a stress test that is ensuring that all the new
> atomic write code paths are not causing anything to break or
> introducing any regressions. This should pass with both atomic or non
> atomic writes but by using RWF_ATOMIC we excercise the atomic specific
> code paths, improving the code coverage.

I am not sure really how much value this has. At least it should be 
documented what we are doing here and what value there is in this test.

Thanks,
John