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: <5485c1ad-8a20-40bc-aa75-68b820de5e1c@oracle.com>
Date: Thu, 3 Apr 2025 16:07:04 +0100
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, linux-api@...r.kernel.org
Subject: Re: [PATCH RFC] statx.2: Add stx_atomic_write_unit_max_opt

On 23/03/2025 06:40, Christoph Hellwig wrote:

I'm not happy with the name stx_atomic_write_unit_max_opt - it's vague 
and subjective.

So I am thinking one of these:
a. stx_atomic_write_unit_max_dev
b. stx_atomic_write_unit_max_bdev
c. stx_atomic_write_unit_max_align
d. stx_atomic_write_unit_max_hw

The terms dev (or device) and bdev are already used in the meaning of 
some members in struct statx, so not too bad. However, when we support 
large atomic writes for XFS rtvol, the bdev atomic write limit and 
rtextsize would influence this value (so just bdev might be a bit 
misleading in the name).

As for stx_atomic_write_unit_max_align, it would mean "max 
alignment/granularity" for possible HW offload. Not great.

stx_atomic_write_unit_max_hw would match the bdev request queue sysfs 
names, but that it a different concept to statx. And it has the same 
issue as bdev for rtvol, above.

Any further suggestions or comments?

> On Fri, Mar 21, 2025 at 10:20:21AM +0000, John Garry wrote:
>> 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.
> 
> Ok, canwe document this somewhere?
> 

Sure, but I want to decide on the name first.. if using 
stx_atomic_write_unit_max_bdev/_dev/hw, then it would be odd that this 
value reports 0 for old kernels (as the bdev limit would never really be 0).

Then if we have rule "stx_atomic_write_unit_max_bdev=0 means that 
stx_atomic_write_unit_max_bdev = stx_atomic_write_unit_max", this breaks 
for when we solely rely on FS-based atomics, as 
stx_atomic_write_unit_max_bdev would be 0 there and that should really 
mean 0 (and not stx_atomic_write_unit_max).

So then we should have a new mask to fetch this field, which is not 
ideal, but ok.