From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1945926AbWBDMIh (ORCPT ); Sat, 4 Feb 2006 07:08:37 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1945944AbWBDMIh (ORCPT ); Sat, 4 Feb 2006 07:08:37 -0500 Received: from fep01-0.kolumbus.fi ([193.229.0.41]:17346 "EHLO fep01-app.kolumbus.fi") by vger.kernel.org with ESMTP id S1945926AbWBDMIg (ORCPT ); Sat, 4 Feb 2006 07:08:36 -0500 Date: Sat, 4 Feb 2006 14:10:34 +0200 (EET) From: Kai Makisara X-X-Sender: makisara@kai.makisara.local To: Hugh Dickins cc: Mike Christie , James Bottomley , Doug Gilbert , Andrew Morton , linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org Subject: Re: [PATCH] st: don't doublefree pages from scatterlist In-Reply-To: Message-ID: References: <20060104172727.GA320@tau.solarneutrino.net> <20060105201249.GB1795@tau.solarneutrino.net> <20060109033149.GC283@tau.solarneutrino.net> <20060109185350.GG283@tau.solarneutrino.net> <20060118001252.GB821@tau.solarneutrino.net> <43E3BF33.6050705@cs.wisc.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 3 Feb 2006, Hugh Dickins wrote: > On Fri, 3 Feb 2006, Mike Christie wrote: ... > > I ask becuase in that kernel the scatterlist passed into scsi_execute_async > > > > if (scsi_execute_async(STp->device, cmd, direction, > > &((STp->buffer)->sg[0]), bytes, > > > > is not the same one that gets send down to the device/HBA. > > Wow, great info, thanks. > > > scsi_execute_async takes the scatterlist passed to it from st or sg, uses it > > as a hint to build a request + bios, then later when the request is sent to > > the device a new scatterlist is sent to the device and the device does the > > pci/dma operation on that scatterlist from the block/scsi layer. > > Very interesting. James can confirm, but I think that means everybody > can ignore my drivers/scsi/st.c patch for 2.6.16-rc, and the unposted > sg.c patches for the same issue that I was going to send Doug. > The patch st is not necessary now but I don't think it would be a bad idea to include it anyway. My reasoning is based on that the patch is very inexpensive, it basically moves freeing of an array to another place. The reasons for inclusion are: - someone reviewing the code may wonder why the change to 2.6.15.x is not in 2.6.x >= 16; 2.6.16 would need at least a comment about this - it does decouple st from any dependencies about what happens to the s/g array at the lower levels - if the s/g array will at some future time be again passed directly to dma mapping, we would not face the problem again I don't have any firm opinion either way. -- Kai