stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
	linux-scsi@vger.kernel.org, linux-block@vger.kernel.org,
	Jeremy Cline <jeremy@jcline.org>,
	Oleksii Kurochko <olkuroch@cisco.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH] scsi: sd: block: Handle cases where devices come online read-only
Date: Tue, 12 Feb 2019 11:47:12 -0500	[thread overview]
Message-ID: <yq1d0nxuf73.fsf@oracle.com> (raw)
In-Reply-To: <20190212080319.GA10547@infradead.org> (Christoph Hellwig's message of "Tue, 12 Feb 2019 00:03:19 -0800")


Christoph,

>> Some devices come online in write protected state and switch to
>> read-write once they are ready to process I/O requests.
>
> That is really weird.  What kind of devices are these?

There are several. I have many bug reports, ranging from USB sticks to
arrays.

>> Note that per-partition ro settings are lost on revalidate. This has
>> been broken for at least a decade and it will require major surgery to
>> fix. To my knowledge nobody has complained about being unable to make
>> partition read-only settings stick through a revalidate. So hopefully
>> this patch will suffice as a simple fix for stable.
>
> Should we warn when we lost these settings on a revalidate?

Would be nice. But as I wrote, it's going to require major surgery to
the gendisk code to handle this particular scenario correctly since we
currently do not keep any partition state between revalidate calls.

> I have to say I don't like the tristate too much - it seems to allow
> setting a hardware write protected device writable again by user
> interfaction, right?

The original policy was that the user policy was ineffective since the
device setting always won.

Jeremy's patch allowed the user setting to override the device setting
but broke the case where devices subsequently change state at runtime.

My workaround is that the user ioctl ro state, if set, overrides
whatever the device reports. And once the user clears the flag, the
current device setting will take effect on revalidate.

> Should we just have a hardware and a user policy field that are
> separate instead?

All this needs to be completely rewritten. However, my attempt at fixing
it up properly got pretty convoluted and thus unsuitable for stable.

The intent with this patch was merely as a workaround for people stuck
with write-protected drives after boot. The tristate wasn't my first
choice, but it turned out to be the path of least resistance for a
stable fix.

-- 
Martin K. Petersen	Oracle Linux Engineering

  parent reply	other threads:[~2019-02-12 16:47 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-08 23:38 [PATCH] scsi: sd: block: Handle cases where devices come online read-only Martin K. Petersen
2019-02-11 15:50 ` Jeremy Cline
2019-02-12 16:26   ` Martin K. Petersen
2019-02-12  8:03 ` Christoph Hellwig
2019-02-12  8:08   ` Hannes Reinecke
2019-02-12 16:50     ` Martin K. Petersen
2019-02-12 16:47   ` Martin K. Petersen [this message]
2019-02-13  2:57     ` [PATCH v2] scsi: sd: block: Fix regressions in read-only block device handling Martin K. Petersen
2019-02-13  7:13       ` Hannes Reinecke
2019-02-16  3:02       ` Martin K. Petersen
2019-02-19  1:36       ` Ming Lei
2019-02-19 23:26         ` Martin K. Petersen
2019-02-22 14:29       ` Christoph Hellwig
2019-02-27  4:19         ` [PATCH v3] " Martin K. Petersen

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=yq1d0nxuf73.fsf@oracle.com \
    --to=martin.petersen@oracle.com \
    --cc=hch@infradead.org \
    --cc=jeremy@jcline.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=olkuroch@cisco.com \
    --cc=stable@vger.kernel.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).