[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aIh9CSzK6Dl1mAfb@infradead.org>
Date: Tue, 29 Jul 2025 00:49:29 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Hugh Dickins <hughd@...gle.com>, Christian Brauner <brauner@...nel.org>,
Klara Modin <klarasmodin@...il.com>, Arnd Bergmann <arnd@...db.de>,
Anuj Gupta <anuj20.g@...sung.com>, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL 11/14 for v6.17] vfs integrity
On Mon, Jul 28, 2025 at 03:21:21PM -0700, Linus Torvalds wrote:
> Bah. I *hate* this "call blk_get_meta_cap() first" approach. There is
> absolutely *NO* way it is valid for that strange specialized ioctl to
> override any proper traditional ioctl numbers, so calling that code
> first and relying on magic error numbers is simply not acceptable.
>
> I'm going to fix this in my merge by just putting the call to
> blk_get_meta_cap() inside the "default:" case for *after* the other
> ioctl numbers have been checked.
>
> Please don't introduce new "magic error number" logic in the ioctl
> path. The fact that the traditional case of "I don't support this" is
> ENOTTY should damn well tell everybody that we have about SIX DECADES
> of problems in this area. Don't repeat that mistake.
>
> And don't let new random unimportant ioctls *EVER* override the normal
> default ones.
I don't think overrides are intentional here. The problem is that
Christian asked for the flexible size growing decoding here, which
makes it impossible to use the simple and proven ioctl dispatch by
just using another case statement in the switch.
Powered by blists - more mailing lists