From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 2 Feb 2016 23:19:31 +0000 From: Al Viro To: Ross Zwisler Cc: linux-kernel@vger.kernel.org, "J. Bruce Fields" , Andrew Morton , Dan Williams , Dave Chinner , Jan Kara , Jeff Layton , Matthew Wilcox , 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> Sender: linux-kernel-owner@vger.kernel.org List-ID: 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"...