linux-kernel - Re: [GIT PULL] SCSI fixes for 6.10-rc4

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]

Date: Fri, 21 Jun 2024 15:03:35 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: James Bottomley <James.Bottomley@...senpartnership.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, linux-scsi <linux-scsi@...r.kernel.org>, 
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] SCSI fixes for 6.10-rc4

On Fri, 21 Jun 2024 at 14:16, James Bottomley
<James.Bottomley@...senpartnership.com> wrote:
>
> Two fixes: one in the ufs driver fixing an obvious memory leak and the
> other (with a core flag based update) trying to prevent USB crashes by
> stopping the core from issuing a request for the I/O Hints mode page.

Honestly, this mode page issue seems to happen every single time
somebody adds a new query.

Can we place just make the rule be that new mode pages are opt-in, and
*NOT* this kind of broken "opt-out several months later when we
noticed that it inevitably caused problems"?

Because if it isn't some mode page that we have already used for
years, it clearly isn't *that* important.

I'd like to note that the wikipedia page for SCSI mode pages doesn't
even mention 0a/05, and I had to go to some SCSI command document on
seagate.com to find it.

The only other hits on the first page of google? Linux kernel discussions.

That should give people a big heads up that "maybe this thing isn't
very common or commonly known about"?

Which in turn should be a big damn hint to not query it by default.

I've pulled this, but let's aim for this being the LAST TIME we add
some idiotic query for a magical mode page that is mentioned on page
413 in an obscure document, and that didn't exist ten years ago.

Because at this point, blaming "some USB devices" for not reacting
well to it is kind of silly. This isn't our first rodeo. You should
have known about this.

Maybe add a BIG COMMENT in sd_revalidate_disk() to not read random
code pages willy-nilly.

Not that people read comments, but maybe it will remind somebody that
we've done this before, and it never works.

I mean, we literally have this comment for just checking the read-only bit:

                 * First attempt: ask for all pages (0x3F), but only 4 bytes.
                 * We have to start carefully: some devices hang if we ask
                 * for more than is available.

and that's a mode sense command that is at least mentioned on the
wikipedia page.

(And no, I don't consider wikipedia to be somehow special or
authoritative - but it's at least a sign of "does anybody know about
this thing?")

             Linus