linux-kernel - Re: [PATCH 01/21] block: Add atomic write operations to request

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]

Date:   Fri, 10 Nov 2023 09:04:04 +0000
From:   John Garry <john.g.garry@...cle.com>
To:     Christoph Hellwig <hch@....de>
Cc:     axboe@...nel.dk, kbusch@...nel.org, sagi@...mberg.me,
        jejb@...ux.ibm.com, martin.petersen@...cle.com, djwong@...nel.org,
        viro@...iv.linux.org.uk, brauner@...nel.org,
        chandan.babu@...cle.com, dchinner@...hat.com,
        linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-nvme@...ts.infradead.org, linux-xfs@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, tytso@....edu, jbongio@...gle.com,
        linux-api@...r.kernel.org,
        Himanshu Madhani <himanshu.madhani@...cle.com>
Subject: Re: [PATCH 01/21] block: Add atomic write operations to request_queue
 limits

On 10/11/2023 06:23, Christoph Hellwig wrote:
> On Thu, Nov 09, 2023 at 05:01:10PM +0000, John Garry wrote:
>> Generally they come from the same device property. Then since
>> atomic_write_unit_max_bytes must be a power-of-2 (and
>> atomic_write_max_bytes may not be), they may be different.
> How much do we care about supporting the additional slack over the
> power of two version?

I'm not sure yet. It depends on any merging support and splitting 
safeguards introduced.

> 
>> In addition,
>> atomic_write_unit_max_bytes is required to be limited by whatever is
>> guaranteed to be able to fit in a bio.
> The limit what fits into a bio is UINT_MAX, not sure that matters 😄

I am talking about what we guarantee that we can always fit in a bio 
according to request queue limits and bio vector count, e.g. if the 
request queue limits us to 8 segments only, then we can't guarantee to 
fit much in (without splitting) and need to limit atomic_write_unit_max 
accordingly.

> 
>> atomic_write_max_bytes is really only relevant for merging writes. Maybe we
>> should not even expose via sysfs.
> Or we need to have a good separate discussion on even supporting any
> merges.  Willy chimed in that supporting merges was intentional,
> but I'd really like to see numbers justifying it.
> 

So far I have tested on an environment where the datarates are not high 
and any merging benefit was minimal to non-existent. But that is not to 
say it could help elsewhere.

Thanks,
John