linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Duyck <aduyck@mirantis.com>
To: jbottomley@odin.com, hare@suse.de, linux-scsi@vger.kernel.org
Cc: alexander.duyck@gmail.com, martin.petersen@oracle.com,
	linux-kernel@vger.kernel.org, shane.seymour@hpe.com,
	jthumshirn@suse.de
Subject: [PATCH 0/2] scsi: Fix endless loop of ATA hard resets due to VPD reads
Date: Wed, 20 Jan 2016 22:35:15 -0800	[thread overview]
Message-ID: <20160121063039.3803.66.stgit@localhost.localdomain> (raw)

Recent changes to the kernel pulled in during the merge window have
resulted in my system generating an endless loop of the following type of
errors:

[  318.965756] ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  318.968457] ata14.00: configured for UDMA/66
[  318.970656] ata14: EH complete
[  318.984366] ata14.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
[  318.986854] ata14.00: irq_stat 0x40000001
[  318.989138] ata14.00: cmd a0/01:00:00:00:01/00:00:00:00:00/a0 tag 22 dma 16640 in
         Inquiry 12 01 00 00 ff 00res 00/00:00:00:00:00/00:00:00:00:00/00 Emask 0x3 (HSM violation)
[  318.995986] ata14: hard resetting link

I bisected the issue and found the patch responsible for the issue was
commit 09e2b0b14690 "scsi: rescan VPD attributes".  This commit contained
several issues.

First, the commit had changed the behavior in terms of what devices we
called scsi_attach_vpd() for.  As a result we were calling it for devices
that didn't support a scsi_level of 6, SCSI 3, so VPD accesses could
result in errors.

Second, the commit as well as a follow-on patch for it contained a number
of RCU errors.  Specifically the code was structured such that we had
accesses outside of RCU locked regions, and repeated use of the RCU
protected pointer without using the proper accessors.  As such it was
possible to get into a serious corruption situation should a pointer be
updated.

Ultimately neither of these bugs were my root cause.  It turns out the
Marvel Console SCSI device in my system needed to have a flag set to
disable VPD access in order to keep things from looping through the error
repeatedly.  In order to resolve it I had to add the kernel parameter
"scsi_mod.dev_flags=Marvell:Console:0x4000000".  This allowed my system to
boot without any errors, however the first two issues described above are
still relevent so I thought I would provide the patches since I had already
written them up.

---

Alexander Duyck (2):
      scsi: Do not attach VPD to devices that don't support it
      scsi: Fix RCU handling for VPD pages


 drivers/scsi/scsi.c        |   55 ++++++++++++++++++++++++--------------------
 drivers/scsi/scsi_lib.c    |   12 +++++-----
 drivers/scsi/scsi_scan.c   |    3 +-
 drivers/scsi/scsi_sysfs.c  |   14 ++++++-----
 include/scsi/scsi_device.h |   14 +++++++----
 5 files changed, 54 insertions(+), 44 deletions(-)

--

             reply	other threads:[~2016-01-21  6:35 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-21  6:35 Alexander Duyck [this message]
2016-01-21  6:35 ` [PATCH 1/2] scsi: Do not attach VPD to devices that don't support it Alexander Duyck
2016-01-21  7:37   ` Hannes Reinecke
2016-01-21 17:05     ` Alexander Duyck
2016-02-02  1:22     ` Martin K. Petersen
2016-01-21  6:35 ` [PATCH 2/2] scsi: Fix RCU handling for VPD pages Alexander Duyck
2016-01-21  7:40   ` Hannes Reinecke
2016-02-02 10:18 ` [PATCH 0/2] scsi: Fix endless loop of ATA hard resets due to VPD reads Kirill A. Shutemov
2016-02-03  2:45   ` Martin K. Petersen
2016-02-03  6:48     ` Kirill A. Shutemov
2016-02-03 15:27       ` Alexander Duyck
2016-02-04  2:39       ` Martin K. Petersen
2016-02-05 14:54   ` Todd Fujinaka
2016-02-10  2:09     ` 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=20160121063039.3803.66.stgit@localhost.localdomain \
    --to=aduyck@mirantis.com \
    --cc=alexander.duyck@gmail.com \
    --cc=hare@suse.de \
    --cc=jbottomley@odin.com \
    --cc=jthumshirn@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=shane.seymour@hpe.com \
    /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).