public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Linton <jlinton@tributary.com>
To: "dgilbert@interlog.com" <dgilbert@interlog.com>
Cc: Marcus Meissner <meissner@suse.de>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	Linux Kernel List <linux-kernel@vger.kernel.org>
Subject: Re: PATCH: scsi: make scsi reset permissions more relaxed (RFC)
Date: Fri, 30 Aug 2013 11:18:01 -0500	[thread overview]
Message-ID: <5220C5B9.3000908@tributary.com> (raw)
In-Reply-To: <5220945A.2090906@interlog.com>

On 8/30/2013 7:47 AM, Douglas Gilbert wrote:

> I proposed the following patch some time back to give the user space finer
> resolution on resets with the option of stopping the escalation but it has
> gone nowhere: http://marc.info/?l=linux-scsi&m=136104139102048&w=2
> 
> With that patch you might only allow an unprivileged user the
> non-escalating LU and target reset variants.
> 
> If changes are made in that area, we might like to think about adding a new
> RESET variant mapping through to the I_T Nexus Reset TMF.

And a fine, incredibly useful patch it is. To the point of basically being a
requirement for SAN environments. Without it, all kinds of havoc can ensue.

But, the problem of burners going out to lunch, shows why its a stopgap. As most
burners are going to be SATA attached (without an expander), you probably want
to escalate all the way to the host reset if none of the other options work.

With a few other tweaks and the no-escalate patch, its possible to implement
escalation logic outside of the kernel that is aware of the device topology and
individual device states. That way HBA's aren't getting reset under active
functional devices.




      reply	other threads:[~2013-08-30 16:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-30 12:04 PATCH: scsi: make scsi reset permissions more relaxed (RFC) Marcus Meissner
2013-08-30 12:18 ` Hannes Reinecke
2013-08-30 12:47 ` Douglas Gilbert
2013-08-30 16:18   ` Jeremy Linton [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=5220C5B9.3000908@tributary.com \
    --to=jlinton@tributary.com \
    --cc=dgilbert@interlog.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=meissner@suse.de \
    /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