From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Christie Subject: Re: Possible bug in scsi_lib.c:scsi_req_map_sg() Date: Sun, 04 Mar 2007 11:04:13 -0600 Message-ID: <45EAFC0D.3020701@cs.wisc.edu> References: <1173018667.3372.36.camel@mulgrave.il.steeleye.com> <45EAE91F.5070206@cs.wisc.edu> <1173023824.3372.53.camel@mulgrave.il.steeleye.com> <45EAF1F7.9040102@cs.wisc.edu> <1173027096.3372.62.camel@mulgrave.il.steeleye.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]:46759 "EHLO sabe.cs.wisc.edu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751892AbXCDREk (ORCPT ); Sun, 4 Mar 2007 12:04:40 -0500 In-Reply-To: <1173027096.3372.62.camel@mulgrave.il.steeleye.com> Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: James Bottomley Cc: "Dachepalli, Sudhir" , Benny Halevy , Jens Axboe , Boaz Harrosh , linux-scsi@vger.kernel.org James Bottomley wrote: > On Sun, 2007-03-04 at 10:21 -0600, Mike Christie wrote: >> I think they get around this and other request settings that need >> resetting by using scsi_execute_async. They will take the command, data >> direction and buffer fields from the original scsi_cmnd, then pass those >> on to scsi_ececute_async which would allocate a new request and then as >> you know that new request gets sent to the scsi layer and looks like a >> brand new request. So I misspoke above. It might be better to say they >> are using it for routing what the other multipath layers would call >> cloned commands. > > But actually, that's what I don't think they want to do. Yeah, you are right. Proper cloning is the better way to go.