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 S1754876AbcBBXTl (ORCPT <rfc822;w@1wt.eu>);
	Tue, 2 Feb 2016 18:19:41 -0500
Received: from zeniv.linux.org.uk ([195.92.253.2]:34754 "EHLO
	ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753395AbcBBXTj (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 2 Feb 2016 18:19:39 -0500
Date: Tue, 2 Feb 2016 23:19:31 +0000
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, "J. Bruce Fields" <bfields@fieldses.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Dan Williams <dan.j.williams@intel.com>,
        Dave Chinner <david@fromorbit.com>, Jan Kara <jack@suse.com>,
        Jeff Layton <jlayton@poochiereds.net>,
        Matthew Wilcox <willy@linux.intel.com>, linux-fsdevel@vger.kernel.org,
        linux-nvdimm@ml01.01.org, xfs@oss.sgi.com
Subject: Re: [PATCH] dax: allow DAX to look up an inode's block device
Message-ID: <20160202231931.GR17997@ZenIV.linux.org.uk>
References: <1454454702-11889-1-git-send-email-ross.zwisler@linux.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1454454702-11889-1-git-send-email-ross.zwisler@linux.intel.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
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 02, 2016 at 04:11:42PM -0700, Ross Zwisler wrote:

> However, for raw block devices and for XFS with a real-time device, the
> value in inode->i_sb->s_bdev is not correct.  With the code as it is
> currently written, an fsync or msync to a DAX enabled raw block device will
> cause a NULL pointer dereference kernel BUG.  For this to work correctly we
> need to ask the block device or filesystem what struct block_device is
> appropriate for our inode.
> 
> To that end, add a get_bdev(struct inode *) entry point to struct
> super_operations.  If this function pointer is non-NULL, this notifies DAX
> that it needs to use it to look up the correct block_device.  If
> i_sb->get_bdev() is NULL DAX will default to inode->i_sb->s_bdev.

Umm...  It assumes that bdev will stay pinned for as long as inode is
referenced, presumably?  If so, that needs to be documented (and verified
for existing fs instances).  In principle, multi-disk fs might want to
support things like "silently move the inodes backed by that disk to other
ones"...