Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp3749647imm; Tue, 29 May 2018 12:56:06 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpUnfkEUtqJp+KRyOUJOynMRX0FsrIMFcxkwO3HM5fG87+w9KM1bTSEECvtfycFtRgKVzTD X-Received: by 2002:a17:902:8f84:: with SMTP id z4-v6mr19187004plo.194.1527623766001; Tue, 29 May 2018 12:56:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527623765; cv=none; d=google.com; s=arc-20160816; b=GRBEA20kYBOUWT1hT/m3z97L6X8P0kS6W3XNQg9WRDN9RS31fxXbq5wr6iHL7c9LQA YBqPPGqUx2Kg9SMEU4dXSTw3ZATbIhUYGNGTUuFnC4qWeCQNl4O1QRQ5uJoL/P9wtiFf jqGBnyLIbzbI+WDEytQlG+eT9Ea7fOh12RGU32ZDiq2XALZTu9qJGbJjc/SVnNfDdfXx jual9YGST23gIBjHJ/zi3CVNdFTGNIYDT5L/j5mmHX31P7+kKiWPuSN95h9XqypgQYoB 9lH/sCNgipdYd1Yo1BNRlpcibm6DzEMUsIzVIJFgbSmUGpJgi7WECEDpVKZHpdxLK05M eD/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=kA6keuN0aNgAVPGkZCyKOdu+SOnVArl3wWaHOpzUuik=; b=jzOY3IScedclh/+UySG2W9+dDPEmRxaikWUVLw+sDs9dopI1AiPF1LWqnzo46/lQAk 3VeLsIxPhDeXO3tiMkHUw3kMYoxdk2wNCzLoiwhVdRse+TC1/acpLh+xthit/uq5Enul 6wvKzXJoWu1QNcZqxoq7txjk/r6tztrAS3+Dmxr0xzjYUnheYAs4M/gXStAWZi/hwQn+ XnmudXKypf8vjtBf+iBkij3luGLnrZ5ySYkXzGoZ26BChLQsNhadjG6dB1nLVQVDJwqa 5EfkkIhJl42mB8QeVLVPqvDQXQQSp7kbHtawXlDkhCAzD2ehh/d/PYkzyKe/rgAbq/mi Ke1w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h189-v6si8684337pge.266.2018.05.29.12.55.51; Tue, 29 May 2018 12:56:05 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966511AbeE2TxC (ORCPT + 99 others); Tue, 29 May 2018 15:53:02 -0400 Received: from mga06.intel.com ([134.134.136.31]:7359 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966533AbeE2TvO (ORCPT ); Tue, 29 May 2018 15:51:14 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 May 2018 12:51:11 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,457,1520924400"; d="scan'208";a="232924734" Received: from theros.lm.intel.com ([10.232.112.164]) by fmsmga006.fm.intel.com with ESMTP; 29 May 2018 12:51:11 -0700 From: Ross Zwisler To: Toshi Kani , Mike Snitzer , dm-devel@redhat.com Cc: Ross Zwisler , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-nvdimm@lists.01.org, linux-xfs@vger.kernel.org Subject: [PATCH v2 4/7] dm: prevent DAX mounts if not supported Date: Tue, 29 May 2018 13:51:03 -0600 Message-Id: <20180529195106.14268-5-ross.zwisler@linux.intel.com> X-Mailer: git-send-email 2.14.3 In-Reply-To: <20180529195106.14268-1-ross.zwisler@linux.intel.com> References: <20180529195106.14268-1-ross.zwisler@linux.intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Currently the code in dm_dax_direct_access() only checks whether the target type has a direct_access() operation defined, not whether the underlying block devices all support DAX. This latter property can be seen by looking at whether we set the QUEUE_FLAG_DAX request queue flag when creating the DM device. This is problematic if we have, for example, a dm-linear device made up of a PMEM namespace in fsdax mode followed by a ramdisk from BRD. QUEUE_FLAG_DAX won't be set on the dm-linear device's request queue, but we have a working direct_access() entry point and the first member of the dm-linear set *does* support DAX. This allows the user to create a filesystem on the dm-linear device, and then mount it with DAX. The filesystem's bdev_dax_supported() test will pass because it'll operate on the first member of the dm-linear device, which happens to be a fsdax PMEM namespace. All DAX I/O will then fail to that dm-linear device because the lack of QUEUE_FLAG_DAX prevents fs_dax_get_by_bdev() from working. This means that the struct dax_device isn't ever set in the filesystem, so dax_direct_access() will always return -EOPNOTSUPP. By failing out of dm_dax_direct_access() if QUEUE_FLAG_DAX isn't set we let the filesystem know we don't support DAX at mount time. The filesystem will then silently fall back and remove the dax mount option, causing it to work properly. Signed-off-by: Ross Zwisler Fixes: commit 545ed20e6df6 ("dm: add infrastructure for DAX support") --- drivers/md/dm.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/md/dm.c b/drivers/md/dm.c index 0a7b0107ca78..9728433362d1 100644 --- a/drivers/md/dm.c +++ b/drivers/md/dm.c @@ -1050,14 +1050,13 @@ static long dm_dax_direct_access(struct dax_device *dax_dev, pgoff_t pgoff, if (!ti) goto out; - if (!ti->type->direct_access) + if (!blk_queue_dax(md->queue)) goto out; len = max_io_len(sector, ti) / PAGE_SECTORS; if (len < 1) goto out; nr_pages = min(len, nr_pages); - if (ti->type->direct_access) - ret = ti->type->direct_access(ti, pgoff, nr_pages, kaddr, pfn); + ret = ti->type->direct_access(ti, pgoff, nr_pages, kaddr, pfn); out: dm_put_live_table(md, srcu_idx); -- 2.14.3