From: Bart Van Assche <bvanassche@acm.org>
To: Linus Torvalds <torvalds@linux-foundation.org>,
"Martin K. Petersen" <martin.petersen@oracle.com>
Cc: James Bottomley <James.Bottomley@hansenpartnership.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-scsi <linux-scsi@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] SCSI fixes for 6.10-rc4
Date: Sat, 22 Jun 2024 09:24:03 -0700 [thread overview]
Message-ID: <8778d191-436d-46cd-a17e-a7d264c32793@acm.org> (raw)
In-Reply-To: <CAHk-=wgLGuYSgbS90MMudryOOjuWYeXaXGeGJRg9SVy1GmLKcQ@mail.gmail.com>
On 6/21/24 6:56 PM, Linus Torvalds wrote:
> But I also know that pretty much *EVERY* time the SCSI layer has
> decided to start looking at some new piece of data, it turns out that
> "Oh, look, all those devices have only ever been tested with operating
> systems that did *NOT* look at that mode page or other thing, and
> surprise surprise - not being tested means that it's buggy".
We got the message and we will do what we can to prevent future
regressions for USB devices.
As has been mentioned earlier, there is evidence in
sd_read_write_protect_flag() that SCSI devices may misbehave when
querying a mode page. However, I was not familiar with that code and
hence was not aware of the comments in that code. According to the git
history, these comments were added before 2005, that is before I started
reading the linux-scsi mailing list.
> My argument is that things should be opt-in.
>
> If it wasn't needed for the previous 30 years go SCSI history, it sure
> as heck didn't suddenly become necessary today.
>
> So you literally NEVER DO THIS unless the system admin has explicitly
> enabled it.
>
> That's what opt-in means.
>
> And honestly, then the Android people can decide to opt in. Not random
> other victims.
>> What's the advantage of just enabling random new features that have no
> real use case today?
>
> Put another way: why wasn't this an explicit opt-in from the get-go?
> And why can't we make that be the rule going forward for the *NEXT*
> time somebody introduces some random new mode page?
The new mode page has been introduced last year in SBC-5. UFS devices
have a mix of SLC and TLC NAND internally and the new mode page allows
device vendors to reduce write amplification. This is important to UFS
device vendors.
I think that the new mode page is useful for all storage devices that
have a mix of slow and fast storage internally and hence that it is also
useful for some enterprise storage devices. This is why the new mode
page is read by default. But as has been mentioned above, we have
learned our lesson and will be much more careful in the future when
adding code that modifies the access pattern of the sd driver for USB
storage devices.
Thanks,
Bart.
next prev parent reply other threads:[~2024-06-22 16:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-21 21:15 [GIT PULL] SCSI fixes for 6.10-rc4 James Bottomley
2024-06-21 22:03 ` Linus Torvalds
2024-06-22 1:48 ` Martin K. Petersen
2024-06-22 1:56 ` Linus Torvalds
2024-06-22 16:24 ` Bart Van Assche [this message]
2024-06-22 16:35 ` Martin K. Petersen
2024-06-21 22:04 ` pr-tracker-bot
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=8778d191-436d-46cd-a17e-a7d264c32793@acm.org \
--to=bvanassche@acm.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--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