On Mon, Oct 05, 2015 at 06:57:19PM -0700, Dan Williams wrote: > On Wed, Sep 30, 2015 at 4:35 PM, Dave Chinner <[email protected]> wrote: > > On Tue, Sep 29, 2015 at 08:41:36PM -0400, Dan Williams wrote: > >> +static void __pmem *__dax_map_bh(const struct buffer_head *bh, unsigned > >> blkbits, > >> + unsigned long *pfn, long *len) > > > > Please don't use bufferheads for this. Please pass an inode, the > > block and length to map, similar to dax_clear_blocks(). > > > > Why? Because dax_clear_blocks() needs to do this "mapping" too, > > and it is called from contexts where there are no bufferheads. > > There's a good chance we'll need more mapping contexts like this in > > future, so lets not propagate bufferheads deeper into this code > > than we absilutely need to. > > > > We should be trying to limit/remove bufferheads in the DAX code, not > > propagating them deeper into the code... > > So I gave this a try but ran into the road block that get_block() is > performing the inode to bdev conversion and that is filesystem > specific. However, I'll at least not pass the bh into this map > routine and will call it dax_map_atomic() which is more accurate.
Right, we still need the bh for the get_block call - that much is unavoidable right now, but I'm angling towards converting XFS to use a struct iomap and ->map_blocks method similar to the exportfs calls for PNFS in future. Having a dedicated structure and set of methods for obtaining and manipulating extent mappings on inodes will make all these bufferhead issues go away... Cheers, Dave. -- Dave Chinner [email protected] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
