From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S933264AbcAaSSt (ORCPT <rfc822;w@1wt.eu>);
	Sun, 31 Jan 2016 13:18:49 -0500
Received: from mail-yk0-f177.google.com ([209.85.160.177]:34937 "EHLO
	mail-yk0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1756351AbcAaSSs (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sun, 31 Jan 2016 13:18:48 -0500
MIME-Version: 1.0
In-Reply-To: <20160131180738.GB2948@linux.intel.com>
References: <1454009704-25959-1-git-send-email-ross.zwisler@linux.intel.com>
	<1454009704-25959-2-git-send-email-ross.zwisler@linux.intel.com>
	<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>
Date: Sun, 31 Jan 2016 10:18:46 -0800
Message-ID: <CAPcyv4hmp3Y6omtDpM_f3rjSbQOvnnugqZCB_Ce+Cg+Q6cWPOA@mail.gmail.com>
Subject: Re: [PATCH 2/2] dax: fix bdev NULL pointer dereferences
From: Dan Williams <dan.j.williams@intel.com>
To: Matthew Wilcox <willy@linux.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>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Sun, Jan 31, 2016 at 10:07 AM, Matthew Wilcox <willy@linux.intel.com> wrote:
> On Sun, Jan 31, 2016 at 08:38:20AM -0800, Dan Williams wrote:
>> On Sun, Jan 31, 2016 at 2:55 AM, Matthew Wilcox <willy@linux.intel.com> wrote:
>> > On Sat, Jan 30, 2016 at 11:12:12PM -0700, Ross Zwisler wrote:
>> >> Is there a reason to store pnfs instead of kaddrs in the radix tree?
>> >
>> > Once ARM, MIPS and SPARC get supported, they're going to need temporary
>> > kernel addresses assigned to PFNs rather than permanent ones.  Also,
>> > it'll be easier for teardown to delete PFNs associated with a particular
>> > device than kaddrs associated with a particular device.  And it lets
>> > us support more persistent memory on a 32-bit machine (also on a 64-bit
>> > machine, but that's mostly theoretical)
>> >
>> > +/*
>> > + * DAX uses the 'exceptional' entries to store PFNs in the radix tree.
>> > + * Bit 0 is clear (the radix tree uses this for its own purposes).  Bit
>> > + * 1 is set (to indicate an exceptional entry).  Bits 2 & 3 are PFN_DEV
>> > + * and PFN_MAP.  The top two bits denote the size of the entry (PTE, PMD,
>> > + * PUD, one reserved).  That leaves us 26 bits on 32-bit systems and 58
>> > + * bits on 64-bit systems, able to address 256GB and 1024EB respectively.
>> > + */
>> >
>> > It's also pretty cheap to look up the kaddr from the pfn, at least on
>> > 64-bit architectures without cache aliasing problems:
>> >
>> > +static void *dax_map_pfn(pfn_t pfn, unsigned long index)
>> > +{
>> > +       preempt_disable();
>> > +       pagefault_disable();
>> > +       return pfn_to_kaddr(pfn_t_to_pfn(pfn));
>>
>> pfn_to_kaddr() assumes persistent memory is direct mapped which is not
>> always the case.
>
> 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?