From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965582AbcBBTHd (ORCPT ); Tue, 2 Feb 2016 14:07:33 -0500 Received: from mail-yw0-f172.google.com ([209.85.161.172]:36630 "EHLO mail-yw0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965423AbcBBTH2 (ORCPT ); Tue, 2 Feb 2016 14:07:28 -0500 X-Greylist: delayed 465 seconds by postgrey-1.27 at vger.kernel.org; Tue, 02 Feb 2016 14:07:28 EST MIME-Version: 1.0 In-Reply-To: <20160202184643.GA3260@linux.intel.com> References: <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> <20160202184643.GA3260@linux.intel.com> Date: Tue, 2 Feb 2016 10:59:41 -0800 Message-ID: Subject: Re: [PATCH 2/2] dax: fix bdev NULL pointer dereferences From: Dan Williams To: Matthew Wilcox Cc: Ross Zwisler , Jan Kara , Dave Chinner , 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 10:46 AM, Matthew Wilcox wrote: > On Tue, Feb 02, 2016 at 09:46:21AM -0800, Dan Williams wrote: >> 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() > > The point is that filesystems have lots of different get_block operations, > and the right one to use depends not just on the inode, but also upon > what VFS function is being called, and in some filesystems the phase > of the moon, or the file open flags (so even inode->i_ops->get_block is > wrong; file->f_ops->get_block would be better, but of course we've lost > that by the point we're doing writeback). True, but in this case we're just trying to resolve the bdev for a inode / sector combination to already allocated storage. So get_block() is a misnomer, this is just get_bdev() to resolve a super_block-inode+sector tuple to a bdev for cases when s_bdev is the wrong answer.