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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Thu, 23 Jun 2022 10:13:34 -0700
From:   Eric Biggers <>
To:     Andreas Dilger <>
Cc:     "Darrick J. Wong" <>,,,,,,,,,, Keith Busch <>
Subject: Re: [man-pages RFC PATCH] statx.2, open.2: document STATX_DIOALIGN

On Thu, Jun 23, 2022 at 10:27:19AM -0600, Andreas Dilger wrote:
> On Jun 23, 2022, at 10:02 AM, Darrick J. Wong <> wrote:
> > 
> > On Thu, Jun 16, 2022 at 01:21:41PM -0700, Eric Biggers wrote:
> >> From: Eric Biggers <>
> >> 
> >> @@ -244,8 +249,11 @@ STATX_SIZE	Want stx_size
> >> STATX_BLOCKS	Want stx_blocks
> >> STATX_BASIC_STATS	[All of the above]
> >> STATX_BTIME	Want stx_btime
> >> +         	This is deprecated and should not be used.
> > 
> > STATX_ALL is deprecated??  I was under the impression that _ALL meant
> > all the known bits for that kernel release, but...
> For userspace STATX_ALL doesn't make sense, and it isn't used by the kernel.
> Firstly, that would be a compile-time value for an application, so it
> may be incorrect for the kernel the code is actually run on (either too
> many or too few bits could be set).
> Secondly, it isn't really useful for an app to request "all attributes"
> if it doesn't know what they all mean, as that potentially adds useless
> overhead.  Better for it to explicitly request the attributes that it
> needs.  If that is fewer than the kernel could return it is irrelevant,
> since the app would ignore them anyway.
> The kernel will already ignore and mask attributes that *it* doesn't
> understand, so requesting more is fine and STATX_ALL doesn't help this.

What Andreas said.  Note, this discussion really should be happening on my
standalone patch that fixes the documentation for STATX_ALL:  I folded
it into this RFC one only so that it applies cleanly without a prerequisite.

- Eric

Powered by blists - more mailing lists