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: <83e05a05-e517-4d41-96ff-da4d49482471@oracle.com>
Date: Mon, 4 Aug 2025 08:12:00 +0100
From: John Garry <john.g.garry@...cle.com>
To: Ojaswin Mujoo <ojaswin@...ux.ibm.com>
Cc: "Darrick J. Wong" <djwong@...nel.org>, 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 02/08/2025 07:49, Ojaswin Mujoo wrote:
> On Fri, Aug 01, 2025 at 09:23:46AM +0100, John Garry wrote:
>> On 01/08/2025 07:41, Ojaswin Mujoo wrote:
>>> Got it, I think I can make this test work for ext4 only but then it might
>>> be more appropriate to run the fio tests directly on atomic blkdev and
>>> skip the FS, since we anyways want to focus on the storage stack.
>>>
>> testing on ext4 will prove also that the FS and iomap behave correctly in
>> that they generate a single bio per atomic write (as well as testing the
>> block stack and below).
> Okay, I think we are already testing those in the ext4/061 ext4/062
> tests of this patchset. Just thought blkdev test might be useful to keep
> in generic. Do you see a value in that or shall I just drop the generic
> overlapping write tests?

If you want to just test fio on the blkdev, then I think that is fine. 
Indeed, maybe such tests are useful in blktests also.

> 
> Also, just for the records, ext4 passes the fio tests ONLY because we use
> the same io size for all threads. If we happen to start overlapping
> RWF_ATOMIC writes with different sizes that can get torn due to racing
> unwritten conversion.

I'd keep the same io size for all threads in the tests.

Thanks,
John

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ