Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp5790330imm; Tue, 26 Jun 2018 18:44:29 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfiUWvO1grKLoBks8vz07ODCmbQ/I6bkLVHdHzjtiwpPtMjZnxtN7TiPsBPeagp3MOB/qLO X-Received: by 2002:a65:4545:: with SMTP id x5-v6mr3393730pgr.4.1530063869302; Tue, 26 Jun 2018 18:44:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530063869; cv=none; d=google.com; s=arc-20160816; b=eyyTiCSEd6QPAfUp/h+BTQu4xE3frxKFNcUSEfLKL7Mvs7C0Ro//7giGK3X8Wjr3P2 xrMzVfjaYaXoqfZWl9Tidtd+OGPq1fccPXtLE6RcN8Iv1nr0apZqnn+WNdJ1Ctiiaksw yipFLNwggHEKnaC0GsqBItugsqiH3H6OQ2FdhIOchhTHVXuDOJViROvVrANv4r5lOIKG +rzEIoLnpr73muW1fncD5TGYBm0aiiq3V1IviN7y7cLsX+tUvchQ+bEuUAeRxb+i8yJo pLxTIcuXnxN165R2hh1fk3cmXHKmm183mXfnQqXS8KGtuu1BYqmpgifk2qF/ET+hES5D o3sQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=QWTyV6SGfEQ5AvgmMC82xtnSWEXVwj9Hv/AitB8Q/dc=; b=yCNFsztBsdy7iMJpmDxejEXSzMdoET5IraT3qEgsa/Uelw7NyMN/DHIWbOXBx0DsnO UKMe/nnPDVgksRW45mUUyqKsntXlZych6jKzsWPg2xrv34Crui+8Md4MvzofpGq7sGBB WUxZ8Z9OmQVDhLhmjYGkIDDjvIdb0ALUQvPd+5C1lPivvGX2BSkjPNiKFwJmP9jjCxzp KE85BZ0wpvh19Uihwhhcj938imDeVKQ5Tk+oS5UFKtn6UbpyVSoXLLhoudf71TNDBs36 n7KyuC6l8TBEmJEdixNlJTqby4RLq+/InlCTChk7mPdjmSKuxmlh9JkD3LtZR0zXOMyz oxBQ== 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 q9-v6si2514589pgn.508.2018.06.26.18.44.14; Tue, 26 Jun 2018 18:44:29 -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 S933299AbeFZWbK (ORCPT + 99 others); Tue, 26 Jun 2018 18:31:10 -0400 Received: from mga06.intel.com ([134.134.136.31]:65177 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752136AbeFZWbI (ORCPT ); Tue, 26 Jun 2018 18:31:08 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jun 2018 15:31:07 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,276,1526367600"; d="scan'208";a="235840883" Received: from theros.lm.intel.com ([10.232.112.164]) by orsmga005.jf.intel.com with ESMTP; 26 Jun 2018 15:31:07 -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 Subject: [PATCH v5 0/3] Fix DM DAX handling Date: Tue, 26 Jun 2018 16:30:38 -0600 Message-Id: <20180626223041.15653-1-ross.zwisler@linux.intel.com> X-Mailer: git-send-email 2.14.4 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This series fixes a few issues that I found with DM's handling of DAX devices. Here are some of the issues I found: * We can create a dm-stripe or dm-linear device which is made up of an fsdax PMEM namespace and a raw PMEM namespace but which can hold a filesystem mounted with the -o dax mount option. DAX operations to the raw PMEM namespace part lack struct page and can fail in interesting/unexpected ways when doing things like fork(), examining memory with gdb, etc. * We can create a dm-stripe or dm-linear device which is made up of an fsdax PMEM namespace and a BRD ramdisk which can hold a filesystem mounted with the -o dax mount option. All I/O to this filesystem will fail. --- Changes since v4: * No code changes. * Updated the changelogs for patches 1 and 3. * Removed the Cc: stable from patch 1. * Added a Fixes: tag to patch 2. Ross Zwisler (3): pmem: only set QUEUE_FLAG_DAX for fsdax mode dax: bdev_dax_supported() check for QUEUE_FLAG_DAX dm: prevent DAX mounts if not supported drivers/dax/super.c | 8 ++++++++ drivers/md/dm-table.c | 7 ++++--- drivers/md/dm.c | 3 +-- drivers/nvdimm/pmem.c | 3 ++- 4 files changed, 15 insertions(+), 6 deletions(-) -- 2.14.4