All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Jeff Garzik <jeff@garzik.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] libata: remove unlock+relock cycle in ata_scsi_queuecmd
Date: Wed, 17 Nov 2010 11:01:13 +0100	[thread overview]
Message-ID: <4CE3A7E9.3010009@kernel.org> (raw)
In-Reply-To: <4CE38D70.4010507@garzik.org>

Hello, Jeff, Linus.

On 11/17/2010 09:08 AM, Jeff Garzik wrote:
> Looking solely at the SCSI code (ie. ignoring LLD code), it seems
> like the magic number zero for serial_number is signaling a boolean
> condition "are we an EH command?"
> 
> EH tests this at the very beginning of the abort/reset/explode error
> handling sequence, presumably to avoid recursive EH invocations
> (scsi_try_to_abort_cmd).
>
> So maybe an EH expert (Tejun?) can correct me here, but I think we
> may be able to completely the lock/get-serial/unlock sequence from
> libata, as long as scsi_init_cmd_errh() reliably sets an "I am an EH
> command" flag.
> 
> Would be nice if true...

Yeah, it's actually nice (for once).  libata doesn't use or care about
scmd->serial_number at all.  The SCSI EH path you mentioned above is
not applicable as libata implements its eh_strategy_handler and SCSI
only calls scsi_try_to_abort_cmd() for the default EH handler,
scsi_unjam_host().

We'll need to test a bit to make sure everything is okay but I'm
fairly certain removing it won't break anything fundamental.  If
something breaks at all, it would be some silly easy-to-fix thing.

Thanks.

-- 
tejun

  parent reply	other threads:[~2010-11-17 10:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-17  6:29 [PATCH] libata: remove unlock+relock cycle in ata_scsi_queuecmd Jeff Garzik
2010-11-17  6:44 ` Linus Torvalds
2010-11-17  8:08   ` Jeff Garzik
2010-11-17  8:13     ` Jeff Garzik
2010-11-17 10:01     ` Tejun Heo [this message]
2010-11-17 15:11       ` Jeff Garzik
2010-11-17 15:28     ` James Bottomley
2010-11-17 15:47       ` Christoph Hellwig
2010-11-17 16:11         ` James Bottomley

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=4CE3A7E9.3010009@kernel.org \
    --to=tj@kernel.org \
    --cc=jeff@garzik.org \
    --cc=linux-ide@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.