From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from mga14.intel.com ([192.55.52.115]:42899 "EHLO mga14.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S933068AbcAaS13 (ORCPT <rfc822;linux-fsdevel@vger.kernel.org>);
	Sun, 31 Jan 2016 13:27:29 -0500
Date: Mon, 1 Feb 2016 05:27:30 +1100
From: Matthew Wilcox <willy@linux.intel.com>
To: Dan Williams <dan.j.williams@intel.com>
Cc: Ross Zwisler <zwisler@gmail.com>,
	linux-nvdimm <linux-nvdimm@ml01.01.org>,
	Dave Chinner <david@fromorbit.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Christoph Hellwig <hch@infradead.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Jan Kara <jack@suse.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 2/2] dax: fix bdev NULL pointer dereferences
Message-ID: <20160131182730.GC2948@linux.intel.com>
References: <20160128213858.GA29114@infradead.org>
 <20160129182815.GB5224@linux.intel.com>
 <20160130052833.GY2948@linux.intel.com>
 <CAPcyv4h-wv6oCK1-=zWM8Av4jaB0oHkSLjfH9Yg3JEZenSrw3Q@mail.gmail.com>
 <20160131023247.GZ2948@linux.intel.com>
 <33D2FA63-0EBC-4E5F-B337-F06A8A846166@gmail.com>
 <20160131105518.GA2948@linux.intel.com>
 <CAA9_cmdeBS6uhxv2dXaPhbT+iQ7qxzX-bTvocdtfJrFz81fc-w@mail.gmail.com>
 <20160131180738.GB2948@linux.intel.com>
 <CAPcyv4hmp3Y6omtDpM_f3rjSbQOvnnugqZCB_Ce+Cg+Q6cWPOA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAPcyv4hmp3Y6omtDpM_f3rjSbQOvnnugqZCB_Ce+Cg+Q6cWPOA@mail.gmail.com>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Sun, Jan 31, 2016 at 10:18:46AM -0800, Dan Williams wrote:
> On Sun, Jan 31, 2016 at 10:07 AM, Matthew Wilcox <willy@linux.intel.com> wrote:
> > Yes.  This is just the default implementation of dax_map_pfn() which works
> > for most situations.  We can introduce more complex implementations of
> > dax_map_pfn() as necessary.  You make another excellent point for why
> > we should store PFNs in the radix tree instead of kaddrs :-)
> 
> How much complexity do we want to add in support of an fsync/msync
> mechanism that is not the recommended way to use DAX?

It actually makes the dax_io path much, much simpler.  And it's not
primarily about fixing fsync/msync.  It also makes the fault path cheaper
in the case where we're refaulting a page that's already been faulted
by another process (or was previously faulted by this process and now
needs to be faulted at a different address).

And it fixes the problem with filesystems that use multiple block_devices.
It also makes DAX much less reliant on buffer heads, which is good for
the problem that Jared raised where he doesn't have a block_device in
an embedded system.