From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from verein.lst.de ([213.95.11.211]:46771 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726487AbeIEXYi (ORCPT ); Wed, 5 Sep 2018 19:24:38 -0400 Date: Wed, 5 Sep 2018 20:56:49 +0200 From: Christoph Hellwig To: Matthew Wilcox Cc: Carlos Maiolino , linux-fsdevel@vger.kernel.org, hch@lst.de, sandeen@redhat.com, david@fromorbit.com Subject: Re: [PATCH 2/2] Use fiemap internal infra-structure to handle FIBMAP Message-ID: <20180905185649.GB423@lst.de> References: <20180905135748.30098-1-cmaiolino@redhat.com> <20180905135748.30098-3-cmaiolino@redhat.com> <20180905143147.GC3729@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180905143147.GC3729@bombadil.infradead.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Sep 05, 2018 at 07:31:47AM -0700, Matthew Wilcox wrote: > On Wed, Sep 05, 2018 at 03:57:48PM +0200, Carlos Maiolino wrote: > > + if (inode->i_op->fiemap) { > > + fextent.fe_logical = 0; > > + fextent.fe_physical = 0; > > + fieinfo.fi_flags = FIEMAP_KERNEL_FIBMAP; > > + fieinfo.fi_extents_max = 1; > > + fieinfo.fi_extents_start = (__force struct fiemap_extent __user *) &fextent; > > + > > + error = inode->i_op->fiemap(inode, &fieinfo, start, 1); > > You'd have to play games with set_fs() and friends if you want to do this. > The fiemap implementation is going to access fi_extents_start with a call > to copy_to_user() and for machines with a 4G/4G split, you need that > address to be interpreted as kernel space, not user space. > > See fiemap_fill_next_extent(): Yeah. I think we need to pass fiemap_fill_next_extent() as a function pointer to fiemap in a prep patch, and then pass a different pointer for the in-kernel usage. Which is good API design anyway, so we should have done this from the beginning.