From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932789AbcAaCct (ORCPT ); Sat, 30 Jan 2016 21:32:49 -0500 Received: from mga03.intel.com ([134.134.136.65]:36528 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932393AbcAaCcs (ORCPT ); Sat, 30 Jan 2016 21:32:48 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,372,1449561600"; d="scan'208";a="39468094" Date: Sun, 31 Jan 2016 13:32:47 +1100 From: Matthew Wilcox To: Dan Williams Cc: Ross Zwisler , Christoph Hellwig , "linux-kernel@vger.kernel.org" , Alexander Viro , Andrew Morton , Dave Chinner , Jan Kara , linux-fsdevel , linux-nvdimm Subject: Re: [PATCH 2/2] dax: fix bdev NULL pointer dereferences Message-ID: <20160131023247.GZ2948@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 29, 2016 at 10:01:13PM -0800, Dan Williams wrote: > On Fri, Jan 29, 2016 at 9:28 PM, Matthew Wilcox wrote: > > If we store the PFN of the underlying page instead, we don't have this > > problem. Instead, we have a different problem; of the device going > > away under us. I'm trying to find the code which tears down PTEs when > > the device goes away, and I'm not seeing it. What do we do about user > > mappings of the device? > > I deferred the dax tear down code until next cycle as Al rightly > pointed out some needed re-works: > > https://lists.01.org/pipermail/linux-nvdimm/2016-January/003995.html Thanks; I eventually found it in my email somewhere over the Pacific. I did probably 70% of the work needed to switch the radix tree over to storing PFNs instead of sectors. It seems viable, though it's a big change from where we are today: fs/dax.c | 415 +++++++++++++++++++++++---------------------- include/linux/dax.h | 3 +- include/linux/pfn_t.h | 33 +++- include/linux/radix-tree.h | 9 - 4 files changed, 236 insertions(+), 224 deletions(-) I'll try and get that finished off this week. One concrete and easily-separable piece is that dax_clear_blocks() has the wrong signature. It currently takes an inode & block as parameters; it has no way of finding out the correct block device. It's only two callers are filesystems (ext2 and xfs). Those filesystems should be passing the block_device instead of the inode. But without the inode, we can't convert a block number to a sector number, so we also need to pass the sector number, not the block number. It still has type sector_t, annoyingly. @@ -63,12 +238,11 @@ static void dax_unmap_atomic(struct block_device *bdev, * and hence this means the stack from this point must follow GFP_NOFS * semantics for all operations. */ -int dax_clear_blocks(struct inode *inode, sector_t block, long _size) +int dax_clear_blocks(struct block_device *bdev, sector_t sector, long size) { - struct block_device *bdev = inode->i_sb->s_bdev; struct blk_dax_ctl dax = { - .sector = block << (inode->i_blkbits - 9), - .size = _size, + .sector = sector, + .size = size, }; might_sleep(); but I haven't looked at doing the conversion of xfs or ext2 to use that new interface.