From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756699AbcBBRrk (ORCPT ); Tue, 2 Feb 2016 12:47:40 -0500 Received: from mail-yk0-f180.google.com ([209.85.160.180]:34322 "EHLO mail-yk0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753861AbcBBRri (ORCPT ); Tue, 2 Feb 2016 12:47:38 -0500 MIME-Version: 1.0 In-Reply-To: References: <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> <20160202164642.GE12574@quack.suse.cz> <20160202173456.GB23963@linux.intel.com> Date: Tue, 2 Feb 2016 09:47:37 -0800 Message-ID: Subject: Re: [PATCH 2/2] dax: fix bdev NULL pointer dereferences From: Dan Williams To: Ross Zwisler , Dan Williams , Jan Kara , Dave Chinner , Matthew Wilcox , Christoph Hellwig , "linux-kernel@vger.kernel.org" , Alexander Viro , Andrew Morton , Jan Kara , linux-fsdevel , linux-nvdimm Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 2, 2016 at 9:46 AM, Dan Williams wrote: > On Tue, Feb 2, 2016 at 9:34 AM, Ross Zwisler > wrote: >> On Tue, Feb 02, 2016 at 09:10:24AM -0800, Dan Williams wrote: >>> On Tue, Feb 2, 2016 at 8:46 AM, Jan Kara wrote: >>> > On Tue 02-02-16 08:33:56, Dan Williams wrote: >>> >> On Tue, Feb 2, 2016 at 3:17 AM, Jan Kara 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. >> >> Oh, no, the primary issue with calling get_block() in the fsync path isn't >> performance. It's that we don't have any idea what get_block() function to >> call. >> >> The fault handler calls all come from the filesystem directly, so they can >> easily give us an appropriate get_block() function pointer. But the >> dax_writeback_mapping_range() calls come from the generic code in >> mm/filemap.c, and don't know what get_block() to pass in. >> >> During one iteration I had the calls to dax_writeback_mapping_range() >> happening in the filesystem fsync code so that it could pass in get_block(), >> but Dave Chinner pointed out that this misses other paths in the filesystem >> that need to have things flushed via a call to filemap_write_and_wait_range(). >> >> In yet another iteration of this series I tried adding get_block() to struct >> inode_operations so that I could access it from what is now >> dax_writeback_mapping_range(), but this was shot down as well. > > Ugh, and we can't trigger it from where a filesystem normally syncs a > block device, becauDid you tryse we lose track of the inode radix [ sorry, copy paste error ] block device, because we lose track of the inode radix > information at that level. > > What a about a super_operation? That seems the right level, given > we're currently doing: > > inode->i_sb->s_bdev > > ...it does not seem terrible to instead do: > > inode->i_sb->s_op->get_block()