linux-kernel - Re: [PATCH 5/6] iomap: Lift blocksize restriction on atomic writes

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: <7e322989-c6e0-424a-94bd-3ad6ce5ffee9@oracle.com>
Date: Fri, 25 Oct 2024 12:07:44 +0100
From: John Garry <john.g.garry@...cle.com>
To: "Ritesh Harjani (IBM)" <ritesh.list@...il.com>, linux-ext4@...r.kernel.org
Cc: Theodore Ts'o <tytso@....edu>, Jan Kara <jack@...e.cz>,
        "Darrick J . Wong" <djwong@...nel.org>,
        Christoph Hellwig
 <hch@...radead.org>,
        Ojaswin Mujoo <ojaswin@...ux.ibm.com>,
        Dave Chinner <david@...morbit.com>, linux-kernel@...r.kernel.org,
        linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 5/6] iomap: Lift blocksize restriction on atomic writes

On 25/10/2024 11:35, Ritesh Harjani (IBM) wrote:
>>> Same as mentioned above. We can't have atomic writes to get split.
>>> This patch is just lifting the restriction of iomap to allow more than
>>> blocksize but the mapped length should still meet iter->len, as
>>> otherwise the writes can get split.
>> Sure, I get this. But I wonder why would we be getting multiple
>> mappings? Why cannot the FS always provide a single mapping?
> FS can decide to split the mappings when it couldn't allocate a single
> large mapping of the requested length. Could be due to -
> - already allocated extent followed by EOF,
> - already allocated extent followed by a hole
> - already mapped extent followed by an extent of different type (e.g. written followed by unwritten or unwritten followed by written)

This is the sort of scenario which I am concerned with. This issue has 
been discussed at length for XFS forcealign support for atomic writes.

So far, the user can atomic write a single FS block regardless of 
whether the extent in which it would be part of is in written or 
unwritten state.

Now the rule will be to write multiple FS blocks atomically, all blocks 
need to be in same written or unwritten state.

This oddity at least needs to be documented.

Better yet would be to not have this restriction.

> - delalloc (not delalloc since we invalidate respective page cache pages before doing DIO).
> - fragmentation or ENOSPC - For ext4 bigalloc this will not happen since
> we reserve the entire cluster. So we know there should be space. But I
> am not sure how other filesystems might end up implementing this functionality.

Thanks,
John