linux-kernel - Re: [PATCH RFC] statx.2: Add stx_atomic_write_unit_max

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: <7311545c-e169-4875-bc6c-97446eea2c45@oracle.com>
Date: Fri, 21 Mar 2025 10:20:21 +0000
From: John Garry <john.g.garry@...cle.com>
To: Christoph Hellwig <hch@....de>
Cc: alx@...nel.org, brauner@...nel.org, djwong@...nel.org, dchinner@...hat.com,
        linux-man@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-xfs@...r.kernel.org, linux-kernel@...r.kernel.org,
        ojaswin@...ux.ibm.com, ritesh.list@...il.com,
        martin.petersen@...cle.com
Subject: Re: [PATCH RFC] statx.2: Add stx_atomic_write_unit_max_opt

On 20/03/2025 14:12, Christoph Hellwig wrote:
> On Thu, Mar 20, 2025 at 09:19:40AM +0000, John Garry wrote:
>> But is there value in reporting this limit? I am not sure. I am not sure
>> what the user would do with this info.
> 
> Align their data structures to it, e.g. size the log buffers to it.
> 

Sure, there may be a usecase there.

So far I am just considering the DB usecase, and they know the atomic 
write size which they want to do, i.e. their internal page size, and 
align to that. If that internal page size <= this opt limit, then good.

>> Maybe, for example, they want to write 1K consecutive 16K pages, each
>> atomically, and decide to do a big 16M atomic write but find that it is
>> slow as bdev atomic limit is < 16M.
>>
>> Maybe I should just update the documentation to mention that for XFS they
>> should check the mounted bdev atomic limits.
> 
> For something working on files having to figure out the underlying
> block device (which is non-trivial given the various methods of
> multi-device support) and then looking into block sysfs is a no-go.
> 
> So if we have any sort of use case for it we should expose the limit.
> 

Coming back to what was discussed about not adding a new flag to fetch 
this limit:

 > Does that actually work?  Can userspace assume all unknown statx
 > fields are padded to zero?

In cp_statx, we do pre-zero the statx structure. As such, the rule "if 
zero, just use hard limit unit max" seems to hold.

 > If so my dio read align change could have
 > done away with the extra flag.

Sounds like it. Maybe this practice is not preferred, i.e. changing what 
the request/result mask returns.