From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Christie Subject: Re: If abort request comes in for command not known to LLD? Date: Fri, 02 Mar 2012 15:10:02 -0600 Message-ID: <4F51372A.8080309@cs.wisc.edu> References: <20120302154438.GE17975@beardog.cce.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from sabe.cs.wisc.edu ([128.105.6.20]:38024 "EHLO sabe.cs.wisc.edu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757162Ab2CBVNb (ORCPT ); Fri, 2 Mar 2012 16:13:31 -0500 In-Reply-To: <20120302154438.GE17975@beardog.cce.hp.com> Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: scameron@beardog.cce.hp.com Cc: linux-scsi@vger.kernel.org On 03/02/2012 09:44 AM, scameron@beardog.cce.hp.com wrote: > > What should the LLD do if an abort request comes into the > abort error handler from the midlayer for a command which is > not known to the LLD? > > I see aic7xxx_osm.c handles it in this way in ahc_linux_queue_recovery_cmd(): > > no_cmd: > /* > * Our assumption is that if we don't have the command, no > * recovery action was required, so we return success. Again, > * the semantics of the mid-layer recovery engine are not > * well defined, so this may change in time. > */ > retval = SUCCESS; > > Is that the right thing to do? Seems a bit weird, but if that's > the right thing to do, I can do that too. > How do you hit this case? I think it is ok. The reasons I have seen drivers hit it this is that race where the driver is completing a command while the timer code is starting to go off, or the cmd has timed out then the driver completes the command before the abort code is run. In those cases the driver has cleaned up its internal accounting because the command has completed. At that point there is not much it can do even if it wanted to. It does not have away to look up things like internal tags/ids for the command.