Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp3749700imm; Tue, 29 May 2018 12:56:11 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoQWQ+UKUajGzPa0bJ0bziVZbSWZqJw8Y2YVUMv78QshOe1+Jx4zyOu6NPuV4cKv3slffp+ X-Received: by 2002:a62:4fd8:: with SMTP id f85-v6mr18782958pfj.77.1527623771048; Tue, 29 May 2018 12:56:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527623771; cv=none; d=google.com; s=arc-20160816; b=QQoPi9ExnL4mXQ+FJvWjlXWKI0JyGC2gKfrwWLV6ya2TOzS3TDilHsB/pZDDzi/4BO R40m0cDyo6TWIKPiUYP1VMkUcyaEgn/ZwgTP+g/9VDMtlCzMGvzb0Pd+h+0tNPDouyOP zgUwtuJb8O8QTpuJgmve89rGU0O1Hmn6KO/+M5lhY1EwNNjaKD8Qvx4WnbLlpOol97nS vcKjgkyTN7IjF9ZfqvP12zLDIhmdVjYzKoEgmdMYC/W/NgaPo0ia4PrgR45AWfWyG14H MaG3AhYyyyxN2E3FgeEYOEtop5LB6Mziy+EVdC89mybvjmwVbxK81qNCspkFLU+WTbJ6 chJw== 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=qanCpA1+QGOhGOLfejPz5Yt/nZHp0tyw8ZpeO66SuW8=; b=uFw6X/mzQuv8zM1kSP5em/MUrtSWDJN0q/vMUijrUz9FAGRj87F576mb4MDZLbSMm1 5y1DWiWc133A6TtMy15fvVSIFGCnvnFK6hXgRpfNG6RWzfdh/SEHo7qAIUGV8RgnGu50 TiKj62b0rwJDQK7wD46rMXjfhucSIEyYR41aWCRNXUcLUPlWc9BNDFypmR/QBH+NUVdp hnQybqihF8b1V0VEThmPd4BzGzGf/gRCOInMiUG0rcH++UxkbkJ929x52VKGIqTb+ePi DNOFgv5haOqEioTE9KqVdegvzLXnRToUF7KLw2oy/gn14jvCa7mNR5C50qpFel4rPDBa oRcw== 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 b65-v6si33313219plb.162.2018.05.29.12.55.56; Tue, 29 May 2018 12:56:11 -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 S966727AbeE2Txv (ORCPT + 99 others); Tue, 29 May 2018 15:53:51 -0400 Received: from mga06.intel.com ([134.134.136.31]:7357 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966532AbeE2TvN (ORCPT ); Tue, 29 May 2018 15:51:13 -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="232924727" 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 3/7] dm: fix test for DAX device support Date: Tue, 29 May 2018 13:51:02 -0600 Message-Id: <20180529195106.14268-4-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 device_supports_dax() just checks to see if the QUEUE_FLAG_DAX flag is set on the device's request queue to decide whether or not the device supports filesystem DAX. This is insufficient because there are devices like PMEM namespaces in raw mode which have QUEUE_FLAG_DAX set but which don't actually support DAX. This means that you could create a dm-linear device, for example, where the first part of the dm-linear device was a PMEM namespace in fsdax mode and the second part was a PMEM namespace in raw mode. Both DM and the filesystem you put on that dm-linear device would think the whole device supports DAX, which would lead to bad behavior once your raw PMEM namespace part using DAX needed struct page for something. Fix this by using bdev_dax_supported() like filesystems do at mount time. This checks for raw mode and also performs other tests like checking to make sure the dax_direct_access() path works. Signed-off-by: Ross Zwisler Fixes: commit 545ed20e6df6 ("dm: add infrastructure for DAX support") --- drivers/md/dm-table.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c index 0589a4da12bb..5bb994b012ca 100644 --- a/drivers/md/dm-table.c +++ b/drivers/md/dm-table.c @@ -885,9 +885,7 @@ EXPORT_SYMBOL_GPL(dm_table_set_type); static int device_supports_dax(struct dm_target *ti, struct dm_dev *dev, sector_t start, sector_t len, void *data) { - struct request_queue *q = bdev_get_queue(dev->bdev); - - return q && blk_queue_dax(q); + return bdev_dax_supported(dev->bdev, PAGE_SIZE); } static bool dm_table_supports_dax(struct dm_table *t) -- 2.14.3