From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966256AbcBDWT1 (ORCPT ); Thu, 4 Feb 2016 17:19:27 -0500 Received: from mga09.intel.com ([134.134.136.24]:5600 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965441AbcBDWTZ (ORCPT ); Thu, 4 Feb 2016 17:19:25 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,397,1449561600"; d="scan'208";a="896632574" Date: Thu, 4 Feb 2016 15:19:19 -0700 From: Ross Zwisler To: Jan Kara Cc: Ross Zwisler , Dan Williams , Dave Chinner , Matthew Wilcox , Christoph Hellwig , "linux-kernel@vger.kernel.org" , Alexander Viro , Andrew Morton , Jan Kara , linux-fsdevel , linux-nvdimm Subject: Re: [PATCH 2/2] dax: fix bdev NULL pointer dereferences Message-ID: <20160204221919.GA27766@linux.intel.com> Mail-Followup-To: Ross Zwisler , Jan Kara , Dan Williams , Dave Chinner , Matthew Wilcox , Christoph Hellwig , "linux-kernel@vger.kernel.org" , Alexander Viro , Andrew Morton , Jan Kara , linux-fsdevel , linux-nvdimm References: <20160201145147.GD13740@quack.suse.cz> <20160201214730.GR20456@dastard> <20160202111723.GD12574@quack.suse.cz> <20160202164642.GE12574@quack.suse.cz> <20160202173456.GB23963@linux.intel.com> <20160203104611.GF12574@quack.suse.cz> <20160204195619.GA31860@linux.intel.com> <20160204202957.GB6895@quack.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160204202957.GB6895@quack.suse.cz> 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 Thu, Feb 04, 2016 at 09:29:57PM +0100, Jan Kara wrote: > On Thu 04-02-16 12:56:19, Ross Zwisler wrote: > > On Wed, Feb 03, 2016 at 11:46:11AM +0100, Jan Kara wrote: <> > > > Let's clear this up a bit: The problem with using ->fsync() method is that > > > it doesn't get called for sync(2). We could use ->sync_fs() to flush caches > > > in case of sync(2) (that's what's happening for normal storage) but the > > > problem with PMEM is that "flush all cached data" operation effectively > > > means iterate through all modified pages and we didn't want to implement > > > this for DAX fsync code. > > > > > > So we have decided to do cache flushing for DAX at a different point - mark > > > inodes which may have writes cached as dirty and use writeback code for the > > > cache flushing. But looking at it now, we have actually chosen a wrong > > > place to do the flushing in the writeback path - note that sync(2) writes > > > data via __writeback_single_inode() -> do_writepages() and thus doesn't > > > even get to filemap_write_and_wait(). > > > > > > So revisiting the decision I see two options: > > > > > > 1) Move the DAX flushing code from filemap_write_and_wait() into > > > ->writepages() fs callback. There the filesystem can provide all the > > > information it needs including bdev, get_block callback, or whatever. > > > > > > 2) Back out even further and implement own tracking and iteration of inodes > > > to write. > > > > > > So far I still think 2) is not worth the complexity (although it would > > > bring DAX code closer to how things behave with standard storage) so I > > > would go for 1). > > > > Jan, just to clarify, are you proposing this change for v4.5 in the remaining > > RCs as an alternative to the get_bdev() patch? > > > > https://lkml.org/lkml/2016/2/2/941 > > Yes, because I don't think anything like ->get_bdev() is needed at all. > Look: dax_do_io(), __dax_fault(), __dax_pmd_fault(), dax_zero_page_range() > don't really need bdev - we have agreed that get_block() fills that in just > fine. > > dax_clear_blocks() has IMO just the wrong signature - it should take bdev > and not inode as an argument. Because combination inode + bdev sector > doesn't really make much sense. > > dax_writeback_mapping_range() is the only remaining offender and it can > easily take bdev as an argument when called from ->writepages(). > > > Or can we move forward with get_bdev(), and try and figure out this new way of > > calling fsync/msync for v4.6? My main concern here is that changing how the > > DAX sync code gets called will affect all three filesystems as well as MM, and > > that it might be too much for RC inclusion... > > I think changes aren't very intrusive so we can feed them in during RC > phase and frankly, you have to move to using ->writepages() anyway to make > sync(2) work reliably. Okay, sounds good. I'll send it out once I've got it working & tested.