Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp5624588imm; Tue, 26 Jun 2018 14:52:50 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKKYDHW9B4iXmh4iEc/mKjkXSkUROFollbcNHzew20nqno8L2uLtlxn9wC4mcmlM/msCKD5 X-Received: by 2002:a17:902:b60c:: with SMTP id b12-v6mr3345455pls.44.1530049970230; Tue, 26 Jun 2018 14:52:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530049970; cv=none; d=google.com; s=arc-20160816; b=LuwrByYH/7IA8m+mmtRDcsSwSNeMLJ/HhDud5B31q5JCc/oMl0Nic2nP6Dgw5rGX8I KyfU/UpRX39U7HvNWl1yyVnRzBKvq5NkhnPVkYBhwrKDT6uwPbtBJXVNX4mF/5OmTQ6L NjFNYF1Gp9lGLNAejGZhv6cbgWH3sfUObjrSoQax/OugbmaO5jqDnWv3gutsGwyhC7As 2/nQ6tmbTROptAUCfwLMdp/01NHU609uggIXYVgARrtKd0IZTS6pElGQvlx5VMdox2i4 Eog3uUIIRF3VBmZGXiRWklaON6QO8wT+TQbbnPHUHdkXpTwk+HugXApAnmvJ6zDa4RL9 vT7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=bPOY96BJG72mktrthVsC54uU6gGLvcgrnNExSO1NslU=; b=K+PBL5lgsWHEB9m+MoMbHiAArPUVTifCnqX/ojWC3B4rAahByjVPR/2iB/v3Pc+78C lrMsLAhNHXPsJK+a0nH9/VgylC5ovLyRbNfdSuCIML+rSB3Vnx09LAXcSraqaSkIhSOF vc+zPoH9X1XOc8qcNpro3nd0daiGxMV2744cZk/kag7PZA4lJ15i/fi4FEXrVMTY39Oq XS2fB7subhiUXBUqDMYqrakH5luylyjb3FiXleTJhXrhy/U/NVNTI8WeahoNj7V6p2Rh 7CnT/AmbnjuB2B14T9fP3ctDGhQH60iPE3yNN+J8/2Uj5N8oG5KuhtSB8pyKXA3Fk9Rf sU8A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=2EVQMI9+; 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 f90-v6si2501392plf.390.2018.06.26.14.52.35; Tue, 26 Jun 2018 14:52:50 -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; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=2EVQMI9+; 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 S1752926AbeFZVv5 (ORCPT + 99 others); Tue, 26 Jun 2018 17:51:57 -0400 Received: from mail-ot0-f194.google.com ([74.125.82.194]:35698 "EHLO mail-ot0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752258AbeFZVvy (ORCPT ); Tue, 26 Jun 2018 17:51:54 -0400 Received: by mail-ot0-f194.google.com with SMTP id a6-v6so6202179otf.2 for ; Tue, 26 Jun 2018 14:51:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bPOY96BJG72mktrthVsC54uU6gGLvcgrnNExSO1NslU=; b=2EVQMI9+VRGOSYuR9di3/zipvnY/Zm1dx1jNSdSd77z7CPDZ8/79vMfnVAqQpuMmVn rzbU2rLOmqC+kCtpVqE0UWEDlo1Y63uOCHCXZYSC2mCLAh+mUcV5pPPm+whtZq0EA66p c/YQFSfTIybWtosi6ehXN6whZosOQH/OX89/S29QuUysyUaRaZjMQ5k8zahRq8FJ7vP5 xhQjgPj55E5w/uzHE0SL90sbQDCqLJeeO6uzUeh7ZrZFaGIImdclZ58AXUTN4kzcpQeB 6DInqlu5FTfvsIG8Hn7xiP6bvm1Y3VR0LDG0pkOJjQfhaNx4UoFN8nYyr4sSSdOTH4lE rs1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bPOY96BJG72mktrthVsC54uU6gGLvcgrnNExSO1NslU=; b=H5k0LtAKHsWQD+5ZxskUvHpzazzgyTH9hGfe8ElwVpINOvbI9M9BO2dNaItEd0AkG2 UkEbTa7+mQpOtunQVJ1gfSJCEJeq9t+fG5Bru12IAByAqinygT2I1g6lMvmBLpMCYV+d Cj2LiMWzcHr3T4navZXGRz1u9DnyVMy0EXvTdcKqJMrTjdcFSWrHm+2tcEp21UnxHLNf 6xtnum4mrnXFbkNQSOCZQcyKKnRzyOaUcJYHBh2ugXFp9G9PyA4+wG6lJ+0+pe8RYx3/ vZslmH3J7i7UBUVvcgPQla1vH8m34U+midzIUzerIOpmL7wR/HF5Nm9pPBNwDD479jxV rp1A== X-Gm-Message-State: APt69E2HiY+xfFE7ei3SEFemLGDwGwtTZm++66YDbqQA7sGhBeKgHZBm JBTNuc9ytbNyGKSPHOO7PXfLjW5AVLvcdaXV4lGoIQ== X-Received: by 2002:a9d:7311:: with SMTP id e17-v6mr1834834otk.162.1530049913801; Tue, 26 Jun 2018 14:51:53 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:38c2:0:0:0:0:0 with HTTP; Tue, 26 Jun 2018 14:51:52 -0700 (PDT) In-Reply-To: <1530048545.14039.288.camel@hpe.com> References: <20180626175932.8899-1-ross.zwisler@linux.intel.com> <20180626175932.8899-2-ross.zwisler@linux.intel.com> <20180626185830.GA7171@redhat.com> <20180626191346.GA7233@redhat.com> <1530046327.14039.273.camel@hpe.com> <1530048093.14039.286.camel@hpe.com> <1530048545.14039.288.camel@hpe.com> From: Dan Williams Date: Tue, 26 Jun 2018 14:51:52 -0700 Message-ID: Subject: Re: [PATCH v3 1/3] pmem: only set QUEUE_FLAG_DAX for fsdax mode To: "Kani, Toshi" Cc: "linux-kernel@vger.kernel.org" , "linux-xfs@vger.kernel.org" , "snitzer@redhat.com" , "stable@vger.kernel.org" , "linux-nvdimm@lists.01.org" , "linux-fsdevel@vger.kernel.org" , "ross.zwisler@linux.intel.com" , "dm-devel@redhat.com" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 26, 2018 at 2:31 PM, Kani, Toshi wrote: > On Tue, 2018-06-26 at 14:28 -0700, Dan Williams wrote: >> On Tue, Jun 26, 2018 at 2:23 PM, Kani, Toshi wrote: >> > On Tue, 2018-06-26 at 14:02 -0700, Dan Williams wrote: >> > > On Tue, Jun 26, 2018 at 1:54 PM, Kani, Toshi wrote: >> >> [..] >> > > > When this dm change was made, the pmem driver supported DAX for both raw >> > > > and memory modes (note: sector mode does not use the pmem driver). I >> > > > think the issue was introduced when we dropped DAX support from raw >> > > > mode. >> > > >> > > Still DAX with raw mode never really worked any way. It was also >> > > something that was broken from day one. So what happens to someone who >> > > happened to avoid all the problems with page-less DAX and enabled >> > > device-mapper on top? That failure mode detail needs to be added to >> > > this changelog if we want to propose this for -stable. >> > >> > My point is that the behavior should be consistent between pmem and >> > device-mapper. When -o dax succeeds on a pmem, then it should succeed >> > on a device-mapper on top of that pmem. >> > >> > Has the drop of dax support from raw mode made to -stable back to the >> > baseline accepted 545ed20e6df6? It will introduce inconsistency, >> > otherwise. >> >> That commit, 569d0365f571 "dax: require 'struct page' by default for >> filesystem dax", has not been tagged for -stable. > > Then, Fixes tag should be set to 569d0365f571 to keep the behavior > consistent. Sure, and the failure mode is...? I'm thinking the commit log should say: "Starting with commit 569d0365f571 "dax: require 'struct page' by default for filesystem dax", dax is no longer supported for page-less configurations. However, device-mapper sees the QUEUE_FLAG_DAX still being set and falsely assumes that DAX is enabled, this leads to "