lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 7 Oct 2015 08:15:25 +1100 From: Dave Chinner <david@...morbit.com> To: Dan Williams <dan.j.williams@...el.com> Cc: Jens Axboe <axboe@...nel.dk>, Boaz Harrosh <boaz@...xistor.com>, "linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Ross Zwisler <ross.zwisler@...ux.intel.com>, Christoph Hellwig <hch@....de> Subject: Re: [PATCH 2/2] block, dax: fix lifetime of in-kernel dax mappings On Mon, Oct 05, 2015 at 06:57:19PM -0700, Dan Williams wrote: > On Wed, Sep 30, 2015 at 4:35 PM, Dave Chinner <david@...morbit.com> 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 david@...morbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists