From patchwork Thu Oct 22 16:05:46 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dan Williams X-Patchwork-Id: 7465731 Return-Path: X-Original-To: patchwork-linux-nvdimm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 1CDFEBF90C for ; Thu, 22 Oct 2015 16:06:24 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 199E2205F4 for ; Thu, 22 Oct 2015 16:06:23 +0000 (UTC) Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9B41F20661 for ; Thu, 22 Oct 2015 16:06:15 +0000 (UTC) Received: from ml01.vlan14.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 8028F6039C; Thu, 22 Oct 2015 09:06:15 -0700 (PDT) X-Original-To: linux-nvdimm@lists.01.org Delivered-To: linux-nvdimm@lists.01.org Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by ml01.01.org (Postfix) with ESMTP id 350116039C for ; Thu, 22 Oct 2015 09:06:14 -0700 (PDT) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga102.jf.intel.com with ESMTP; 22 Oct 2015 09:05:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,183,1444719600"; d="scan'208";a="669639102" Received: from orsmsx104.amr.corp.intel.com ([10.22.225.131]) by orsmga003.jf.intel.com with ESMTP; 22 Oct 2015 09:05:48 -0700 Received: from orsmsx107.amr.corp.intel.com ([169.254.1.53]) by ORSMSX104.amr.corp.intel.com ([169.254.3.184]) with mapi id 14.03.0248.002; Thu, 22 Oct 2015 09:05:47 -0700 From: "Williams, Dan J" To: "jack@suse.cz" Subject: Re: [PATCH 5/5] block: enable dax for raw block devices Thread-Topic: [PATCH 5/5] block: enable dax for raw block devices Thread-Index: AQHRDJWpFpZwVt7ww02fEDBKc5eLI553tj+AgABs8oA= Date: Thu, 22 Oct 2015 16:05:46 +0000 Message-ID: <1445529945.17208.4.camel@intel.com> References: <20151022064142.12700.11849.stgit@dwillia2-desk3.amr.corp.intel.com> <20151022064211.12700.77105.stgit@dwillia2-desk3.amr.corp.intel.com> <20151022093549.GE14445@quack.suse.cz> In-Reply-To: <20151022093549.GE14445@quack.suse.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.140] Content-ID: <0B5FD146F4C0674B9E174AA9A408A4A2@intel.com> MIME-Version: 1.0 Cc: "linux-nvdimm@lists.01.org" , "david@fromorbit.com" , "linux-kernel@vger.kernel.org" , "axboe@fb.com" , "akpm@linux-foundation.org" , "hch@lst.de" X-BeenThere: linux-nvdimm@lists.01.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Linux-nvdimm developer list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Thu, 2015-10-22 at 11:35 +0200, Jan Kara wrote: > On Thu 22-10-15 02:42:11, Dan Williams wrote: > > If an application wants exclusive access to all of the persistent memory > > provided by an NVDIMM namespace it can use this raw-block-dax facility > > to forgo establishing a filesystem. This capability is targeted > > primarily to hypervisors wanting to provision persistent memory for > > guests. > > > > Cc: Jan Kara > > Cc: Jeff Moyer > > Cc: Christoph Hellwig > > Cc: Dave Chinner > > Cc: Andrew Morton > > Cc: Ross Zwisler > > Signed-off-by: Dan Williams > > --- > > fs/block_dev.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++++++++- > > 1 file changed, 53 insertions(+), 1 deletion(-) > > > > diff --git a/fs/block_dev.c b/fs/block_dev.c > > index 3255dcec96b4..c27cd1a21a13 100644 > > --- a/fs/block_dev.c > > +++ b/fs/block_dev.c > > @@ -1687,13 +1687,65 @@ static const struct address_space_operations def_blk_aops = { > > .is_dirty_writeback = buffer_check_dirty_writeback, > > }; > > > > +#ifdef CONFIG_FS_DAX > > +/* > > + * In the raw block case we do not need to contend with truncation nor > > + * unwritten file extents. Without those concerns there is no need for > > + * additional locking beyond the mmap_sem context that these routines > > + * are already executing under. > > + * > > + * Note, there is no protection if the block device is dynamically > > + * resized (partition grow/shrink) during a fault. A stable block device > > + * size is already not enforced in the blkdev_direct_IO path. > > + * > > + * For DAX, it is the responsibility of the block device driver to > > + * ensure the whole-disk device size is stable while requests are in > > + * flight. > > + * > > + * Finally, these paths do not synchronize against freezing > > + * (sb_start_pagefault(), etc...) since bdev_sops does not support > > + * freezing. > > Well, for devices freezing is handled directly in the block layer code > (blk_stop_queue()) since there's no need to put some metadata structures > into a consistent state. So the comment about bdev_sops is somewhat > strange. This text was aimed at the request from Ross to document the differences vs the generic_file_mmap() path. Is the following incremental change more clear? diff --git a/fs/block_dev.c b/fs/block_dev.c index 840acd4380d4..4ae8fa55bd1e 100644 --- a/fs/block_dev.c +++ b/fs/block_dev.c @@ -1702,9 +1702,15 @@ static const struct address_space_operations def_blk_aops = { * ensure the whole-disk device size is stable while requests are in * flight. * - * Finally, these paths do not synchronize against freezing - * (sb_start_pagefault(), etc...) since bdev_sops does not support - * freezing. + * Finally, in contrast to the generic_file_mmap() path, there are no + * calls to sb_start_pagefault(). That is meant to synchronize write + * faults against requests to freeze the contents of the filesystem + * hosting vma->vm_file. However, in the case of a block device special + * file, it is a 0-sized device node usually hosted on devtmpfs, i.e. + * nothing to do with the super_block for bdev_file_inode(vma->vm_file). + * We could call get_super() in this path to retrieve the right + * super_block, but the generic_file_mmap() path does not do this for + * the CONFIG_FS_DAX=n case. */ static int blkdev_dax_fault(struct vm_area_struct *vma, struct vm_fault *vmf) {