linux-kernel - Re: [PATCH 16/21] fs: iomap: 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b50b7972-4990-9bc7-2f5f-4475011272d5@oracle.com>
Date:   Tue, 24 Oct 2023 13:59:41 +0100
From:   John Garry <john.g.garry@...cle.com>
To:     Dave Chinner <david@...morbit.com>
Cc:     axboe@...nel.dk, kbusch@...nel.org, hch@....de, 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
Subject: Re: [PATCH 16/21] fs: iomap: Atomic write support

On 03/10/2023 05:24, Dave Chinner wrote:

I don't think that this was ever responded to - apologies for that.

>> 		n = bio->bi_iter.bi_size;
>> +		if (atomic_write && n != length) {
>> +			/* This bio should have covered the complete length */
>> +			ret = -EINVAL;
>> +			bio_put(bio);
>> +			goto out;
> Why? The actual bio can be any length that meets the aligned
> criteria between min and max, yes?
> So it's valid to split a
> RWF_ATOMIC write request up into multiple min unit sized bios, is it
> not?

It is not.

> I mean, that's the whole point of the min/max unit setup, isn't
> it?

atomic write unit min/max are lower and upper limits for the atomic 
write length only.

> That the max sized write only guarantees that it will tear at
> min unit boundaries, not within those min unit boundaries?

We will never split an atomic write nor create multiple bios for an 
atomic write. unit min is the minimum size supported for an atomic write 
length. It is not also a boundary size which we may split a write. An 
atomic write will only ever produce a maximum for a single IO operation. 
We do support merging of atomic writes in the block layer, but this is 
transparent to the user.

Please let me know if 
https://lore.kernel.org/linux-api/20230929093717.2972367-1-john.g.garry@oracle.com/T/#mb48328cf84b1643b651b5f1293f443e26f18fbb5 
needs to be improved to make this clear.

> If
> I've understood this correctly, then why does this "single bio for
> large atomic write" constraint need to exist?
> 
> 

Thanks,
John