On Fri, Mar 02, 2012 at 03:10:02PM -0600, Mike Christie wrote: > On 03/02/2012 09:44 AM, scameron@xxxxxxxxxxxxxxxxxx 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'm not quite sure. I haven't hit it, but have a report of it on RHEL5u5 with XFS filesystem under heavy load. As a guess, I'd say a race between driver completing the command and a timeout in the mid layer. In any case, it'd be nice to know what the kernel expects a driver to do if it should encounter that situation. > > 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. Right, but it just seems weird for the driver to effectively say, "Sure, I aborted that command", when it did no such thing. If the driver tells the kernel that a write got aborted when really it was completed, that seems like it could be kind of bad. -- steve -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
