From: Christoph Hellwig <hch@infradead.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Hugh Dickins <hughd@google.com>,
Christian Brauner <brauner@kernel.org>,
Klara Modin <klarasmodin@gmail.com>,
Arnd Bergmann <arnd@arndb.de>, Anuj Gupta <anuj20.g@samsung.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [GIT PULL 11/14 for v6.17] vfs integrity
Date: Tue, 29 Jul 2025 00:49:29 -0700 [thread overview]
Message-ID: <aIh9CSzK6Dl1mAfb@infradead.org> (raw)
In-Reply-To: <CAHk-=wg2-ShOw7JO2XJ6_SKg5Q0AWYBtxkVzq6oPnodhF9w4=A@mail.gmail.com>
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.
next prev parent reply other threads:[~2025-07-29 7:49 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-25 11:27 [GIT PULL 00/14 for v6.17] vfs 6.17 Christian Brauner
2025-07-25 11:27 ` [GIT PULL 05/14 for v6.17] vfs async dir Christian Brauner
2025-07-28 23:40 ` pr-tracker-bot
2025-07-25 11:27 ` [GIT PULL 09/14 for v6.17] vfs bpf Christian Brauner
2025-07-28 23:40 ` pr-tracker-bot
2025-07-29 18:15 ` Alexei Starovoitov
2025-07-31 8:27 ` Christian Brauner
2025-07-31 21:57 ` Alexei Starovoitov
2025-08-04 14:24 ` Christian Brauner
2025-07-25 11:27 ` [GIT PULL 02/14 for v6.17] vfs coredump Christian Brauner
2025-07-28 18:57 ` Linus Torvalds
2025-07-31 9:37 ` Christian Brauner
2025-07-28 23:40 ` pr-tracker-bot
2025-07-25 11:27 ` [GIT PULL 06/14 for v6.17] vfs fallocate Christian Brauner
2025-07-28 23:40 ` pr-tracker-bot
2025-07-25 11:27 ` [GIT PULL 12/14 for v6.17] vfs fileattr Christian Brauner
2025-07-28 23:40 ` pr-tracker-bot
2025-07-25 11:27 ` [GIT PULL 11/14 for v6.17] vfs integrity Christian Brauner
2025-07-28 1:29 ` Hugh Dickins
2025-07-28 22:21 ` Linus Torvalds
2025-07-29 7:49 ` Christoph Hellwig [this message]
2025-07-29 8:39 ` Linus Torvalds
2025-07-31 8:00 ` Christian Brauner
2025-07-28 23:40 ` pr-tracker-bot
2025-07-25 11:27 ` [GIT PULL 14/14 for v6.17] vfs iomap Christian Brauner
2025-07-27 13:10 ` Sasha Levin
2025-07-28 16:39 ` Joanne Koong
2025-07-31 8:29 ` Christian Brauner
2025-07-28 23:40 ` pr-tracker-bot
2025-07-25 11:27 ` [GIT PULL 01/14 for v6.17] vfs misc Christian Brauner
2025-07-28 23:40 ` pr-tracker-bot
2025-07-25 11:27 ` [GIT PULL 07/14 for v6.17] vfs mmap Christian Brauner
2025-07-28 23:40 ` pr-tracker-bot
2025-07-25 11:27 ` [GIT PULL 04/14 for v6.17] namespace updates Christian Brauner
2025-07-28 23:40 ` pr-tracker-bot
2025-07-25 11:27 ` [GIT PULL 03/14 for v6.17] overlayfs Christian Brauner
2025-07-28 23:40 ` pr-tracker-bot
2025-07-25 11:27 ` [GIT PULL 08/14 for v6.17] vfs pidfs Christian Brauner
2025-07-28 23:40 ` pr-tracker-bot
2025-07-25 11:27 ` [GIT PULL 10/14 for v6.17] vfs rust Christian Brauner
2025-07-28 23:40 ` pr-tracker-bot
2025-07-25 11:27 ` [GIT PULL 13/14 for v6.17] vfs super Christian Brauner
2025-07-28 23:40 ` pr-tracker-bot
2025-07-31 9:40 ` [GIT PULL 00/14 for v6.17] vfs 6.17 Christian Brauner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aIh9CSzK6Dl1mAfb@infradead.org \
--to=hch@infradead.org \
--cc=anuj20.g@samsung.com \
--cc=arnd@arndb.de \
--cc=brauner@kernel.org \
--cc=hughd@google.com \
--cc=klarasmodin@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).