linux-kernel - Re: [GIT PULL] vfs dio

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: <CAHk-=wj+uVo3sJU3TKup0QfftWaEXcaiH4aBqnuM09eUDdo=og@mail.gmail.com>
Date: Mon, 20 Jan 2025 11:24:56 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Christian Brauner <brauner@...nel.org>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] vfs dio

On Sat, 18 Jan 2025 at 05:09, Christian Brauner <brauner@...nel.org> wrote:
>
> Add a separate dio read align field to statx, as many out of place write
> file systems can easily do reads aligned to the device sector size, but
> require bigger alignment for writes.

I've pulled this, but it needs some fixing.

You added the 'dio_read_offset_align' field to 'struct kstat', and
that structure is *critical*, because it's used even for the real
'stat()' calls that people actually use (as opposed to the statx side
that is seldom a real issue).

And that field was added in a way that causes the struct to grow due
to alignment issues.  For no good reason, because there were existing
holes in there.

So please just fix it.

I despise the whole statx thing exactly because it has (approximately)
five specialized users, while slowing down regular stat/fstat that is
used widely absolutely *evertwhere*.

Of course, judging by past performance, I wouldn't be surprised if
glibc has screwed the pooch, and decided to use 'statx()' to implement
stat, together with extra pointless user space overhead to convert one
into the other. Because that's the glibc way (ie the whole "turn
fstat() into the much slower fstatat() call, just because").

So here's the deal: 'statx()' is *not* an "improved stat". It's an
actively worse stat() for people who need very unusual and specialized
information, and it makes everything else worse.

              Linus