From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Christie Subject: Re: [PATCH] Eliminate error handler overload of the SCSI serial number Date: Thu, 18 Nov 2010 13:36:18 -0600 Message-ID: <4CE58032.8040304@cs.wisc.edu> References: <1290010257.4736.50.camel@mulgrave.site> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from sabe.cs.wisc.edu ([128.105.6.20]:32777 "EHLO sabe.cs.wisc.edu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753461Ab0KRT2m (ORCPT ); Thu, 18 Nov 2010 14:28:42 -0500 In-Reply-To: <1290010257.4736.50.camel@mulgrave.site> Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: James Bottomley Cc: linux-scsi , Christoph Hellwig , Mike Anderson On 11/17/2010 10:10 AM, James Bottomley wrote: > -static int scsi_try_to_abort_cmd(struct scsi_cmnd *scmd) > -{ > - /* > - * scsi_done was called just after the command timed out and before > - * we had a chance to process it. (db) > - */ > - if (scmd->serial_number == 0) > - return SUCCESS; > - return __scsi_try_to_abort_cmd(scmd); > -} Does it matter that with this patch we now call the driver's abort handler when the command has been added to the eh list when going through scsi_softirq_done-> scsi_decide_disposition returns FAILED -> scsi_eh_scmd_add? It looks like most drivers will not send an abort, because they check something like the scsi_cmnd SCp pointer for their internal info and when it is not there they assume the command completed and just return (do some return FAILED and some return SUCCESS through). I did not check all drivers. It seems like this is a really rare case that we get FAILED from scsi_decide_disposition so I thought it might not matter.