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 S964936AbcBBRK2 (ORCPT <rfc822;w@1wt.eu>);
	Tue, 2 Feb 2016 12:10:28 -0500
Received: from mail-yk0-f169.google.com ([209.85.160.169]:33988 "EHLO
	mail-yk0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S964920AbcBBRKZ (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 2 Feb 2016 12:10:25 -0500
MIME-Version: 1.0
In-Reply-To: <20160202164642.GE12574@quack.suse.cz>
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>
	<20160201145147.GD13740@quack.suse.cz>
	<20160201214730.GR20456@dastard>
	<20160202111723.GD12574@quack.suse.cz>
	<CAPcyv4j8MtNrsW86HepcS3JdO-Gkt+PCcS5GdPi1m3jwCsJ+nQ@mail.gmail.com>
	<20160202164642.GE12574@quack.suse.cz>
Date: Tue, 2 Feb 2016 09:10:24 -0800
Message-ID: <CAPcyv4hsChZS4Qv7XHpZm-qYuPrpTqgcpBC56jazE+y=B7q3CQ@mail.gmail.com>
Subject: Re: [PATCH 2/2] dax: fix bdev NULL pointer dereferences
From: Dan Williams <dan.j.williams@intel.com>
To: Jan Kara <jack@suse.cz>
Cc: Dave Chinner <david@fromorbit.com>, Matthew Wilcox <willy@linux.intel.com>,
        Ross Zwisler <ross.zwisler@linux.intel.com>,
        Christoph Hellwig <hch@infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Alexander Viro <viro@zeniv.linux.org.uk>,
        Andrew Morton <akpm@linux-foundation.org>, Jan Kara <jack@suse.com>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        linux-nvdimm <linux-nvdimm@ml01.01.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 Tue, Feb 2, 2016 at 8:46 AM, Jan Kara <jack@suse.cz> wrote:
> On Tue 02-02-16 08:33:56, Dan Williams wrote:
>> On Tue, Feb 2, 2016 at 3:17 AM, Jan Kara <jack@suse.cz> wrote:
>> [..]
>> > I see, thanks for explanation. So I'm OK with changing what is stored in
>> > the radix tree to accommodate this use case but my reservation that we IHMO
>> > have other more pressing things to fix remains...
>>
>> We don't need pfns in the radix to support XFS RT configurations.
>> Just call get_blocks() again and use the sector, or am I missing
>> something?
>
> You are correct. But if you decide to pay the cost of additional
> get_block() call, you only need the dirty tag in the radix tree and nothing
> else. So my understanding was that the whole point of games with radix tree
> is avoiding this extra get_block() calls for fsync().
>

DAX-fsync() is already a potentially expensive operation to cover data
durability guarantees for DAX-unaware applications.  A DAX-aware
application is going to skip fsync, and the get_blocks() cost, to do
cache management itself.

Willy pointed out some other potential benefits, assuming a suitable
replacement for the protections afforded by the block-device
percpu_ref counter can be found.  However, optimizing for the
DAX-unaware-application case seems the wrong motivation to me.