linux-kernel - Re: [PATCH 2/2] block, dax: fix lifetime of in-kernel dax mappings

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20151006211525.GC32150@dastard>
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/