linux-kernel - Re: [Patch v9 05/10] block: Add core atomic write support

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: <1e821eb1-652e-43ce-b1c2-3990a43ed4ba@oracle.com>
Date: Fri, 21 Jun 2024 08:41:56 +0100
From: John Garry <john.g.garry@...cle.com>
To: Hannes Reinecke <hare@...e.de>, axboe@...nel.dk, kbusch@...nel.org,
        hch@....de, sagi@...mberg.me, jejb@...ux.ibm.com,
        martin.petersen@...cle.com, viro@...iv.linux.org.uk,
        brauner@...nel.org, dchinner@...hat.com, jack@...e.cz
Cc: djwong@...nel.org, linux-block@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-nvme@...ts.infradead.org,
        linux-fsdevel@...r.kernel.org, tytso@....edu, jbongio@...gle.com,
        linux-scsi@...r.kernel.org, ojaswin@...ux.ibm.com, linux-aio@...ck.org,
        linux-btrfs@...r.kernel.org, io-uring@...r.kernel.org,
        nilay@...ux.ibm.com, ritesh.list@...il.com, willy@...radead.org,
        agk@...hat.com, snitzer@...nel.org, mpatocka@...hat.com,
        dm-devel@...ts.linux.dev,
        Himanshu Madhani <himanshu.madhani@...cle.com>
Subject: Re: [Patch v9 05/10] block: Add core atomic write support

On 21/06/2024 07:09, Hannes Reinecke wrote:
> On 6/20/24 14:53, John Garry wrote:
> [ .. ]
>> +/*
>> + * Returns max guaranteed bytes which we can fit in a bio.
>> + *
>> + * We request that an atomic_write is ITER_UBUF iov_iter (so a single 
>> vector),
>> + * so we assume that we can fit in at least PAGE_SIZE in a segment, 
>> apart from
>> + * the first and last segments.
>> + */
>> +static
>> +unsigned int blk_queue_max_guaranteed_bio(struct queue_limits *lim)
>> +{
>> +    unsigned int max_segments = min(BIO_MAX_VECS, lim->max_segments);
>> +    unsigned int length;
>> +
>> +    length = min(max_segments, 2) * lim->logical_block_size;
>> +    if (max_segments > 2)
>> +        length += (max_segments - 2) * PAGE_SIZE;
>> +
>> +    return length;
>> +}
>> +
> Now you got me confused.
> 
> Why is the length of an atomic write two times the logical block size?

It's not just that.

> And even if it does, shouldn't an atomic write be aligned to the logical 
> block size, so why would you need to add two additional PAGE_SIZE worth
> of length?
> And even if _that_ would be okay, why PAGE_SIZE? We're trying really 
> hard to get away from implicit PAGE_SIZE assumptions when doing I/O ...
> 

We need to know what is the maximum size which we can guarantee not to 
need to split. And we work on basis of worst case scenario, i.e. least 
efficient packing of data into iovec[]. However we require a UBUF iter 
and that iter will be aligned to LBS, that would mean that first and 
last segment would be at least logical block size and middle segments 
would be at least PAGE_SIZE.

Thanks,
John