From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
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] final round of SCSI updates for the 5.1+ merge window
Date: Sat, 18 May 2019 03:21:04 -0400 [thread overview]
Message-ID: <yq1bm009qjj.fsf@oracle.com> (raw)
In-Reply-To: <CAHk-=wiAdmRv-Piq6LKvgLDgQC+AV-RYK2O-RC09SRRGq3v1cw@mail.gmail.com> (Linus Torvalds's message of "Fri, 17 May 2019 14:20:14 -0700")
Linus,
> No. That code is insane. It looks very fishy indeed to me, and I'm not
> pulling it this late in the game.
Yeah, my mess. Sorry.
A couple of people poked me about this issue last week. I merged the
patch without much scrutiny since several people had commented and
tested when it was originally posted a few months back. In looking over
the changes again, however, I agree with your assertion that it is
fishy.
> Just revert the oneliner SCSI change that caused the regression.
My patch wasn't exclusively trying to address the regression wrt. drives
that temporarily come up read-only. Device or fabric events can also
trigger revalidate and there's a whole can of worms in that department
thanks to the intersection between device characteristics changing and
the partition table potentially being updated. This was my feeble
attempt at fixing several long-standing issues in the read-only device
handling which we occasionally hit.
I'll drop the offending patch and revert Jeremy's change for now. And
then revisit the gorge of eternal peril that is revalidate...
--
Martin K. Petersen Oracle Linux Engineering
prev parent reply other threads:[~2019-05-18 7:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-17 14:44 [GIT PULL] final round of SCSI updates for the 5.1+ merge window James Bottomley
2019-05-17 21:20 ` Linus Torvalds
2019-05-18 7:21 ` Martin K. Petersen [this message]
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=yq1bm009qjj.fsf@oracle.com \
--to=martin.petersen@oracle.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@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