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: <20250120-narrte-spargel-6b0f052af8b6@brauner>
Date: Mon, 20 Jan 2025 20:38:44 +0100
From: Christian Brauner <brauner@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] vfs dio

On Mon, Jan 20, 2025 at 11:24:56AM -0800, Linus Torvalds wrote:
> 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.

Right, sorry I should've noticed that during review.

> 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.

Yes, I'm well aware that you dislike statx(). :) It is heavily used
nowadays though because there's a few additional bits in there that
don't require calling into filesystems but are heavily used.

I want to reiterate that if I'd been involved in statx() I would've done
it as an extensible struct. So v1 of the struct would just be exactly
what stat() was.

This way neither copy-in nor copy-out would have done any unnecessary
work and perf would've been the same. Only when userspace actually
needed additional information it would have to pass in a larger struct
and pay the price for copy-in and copy-out.

I'll get you a new PR soon!