From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Bottomley Subject: Re: [PATCH] dc395x: Fix support for highmem Date: Sat, 23 Apr 2005 15:01:44 -0400 Message-ID: <1114282904.5068.19.camel@mulgrave> References: <20050321075531.GC23911@suse.de> <7044.1111398919@www16.gmx.net> <20050321104419.GH23911@suse.de> <1112220802.9435.1.camel@mulgrave> <20050422113654.GY9371@suse.de> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: Received: from stat16.steeleye.com ([209.192.50.48]:36825 "EHLO hancock.sc.steeleye.com") by vger.kernel.org with ESMTP id S261699AbVDWTB5 (ORCPT ); Sat, 23 Apr 2005 15:01:57 -0400 In-Reply-To: Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: Guennadi Liakhovetski Cc: Jens Axboe , Christoph Hellwig , Matthew Wilcox , SCSI Mailing List , Kurt Garloff On Sat, 2005-04-23 at 12:06 +0200, Guennadi Liakhovetski wrote: > Hm, it is sometimes a good idea to at least compile-test ones patches... > So, the one below at least compiles. > > One more thing I wanted to ask - what can one assume about request > buffers? If it is a sg, I guess, each segment is within one page frame, > right? And if sg is not used, is request_buffer also guaranteed to be > within one page or not? No to the first one if you've enabled clustering or have an IOMMU and no to the second one. As long as the sg list hasn't gone through dma_map_sg, then you can rely on its elements being contiguous in physical space. Once it's gone through dma_map_sg, it's elements are contiguous in the bus space beyond the IOMMU, so no longer (possibly) even physically contiguous. The request_buffer for no sg cases is guaranteed to be both physically and virtually contiguous. James