Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp7990603imm; Thu, 28 Jun 2018 12:39:29 -0700 (PDT) X-Google-Smtp-Source: ADUXVKITkLQuKJFFVVzWL9ybUdy0KEXZcNS47rGMvKFQ9M4nWk8MEq02UxFosdqCf6kBsCkSPnxB X-Received: by 2002:a63:9856:: with SMTP id l22-v6mr10160203pgo.208.1530214768957; Thu, 28 Jun 2018 12:39:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530214768; cv=none; d=google.com; s=arc-20160816; b=Jc2X5pD5Hct0FvJ4TdMpGa9BySzdeN6o3KBfEejO0ehyev6jvaEjJS8P/pMU/GgoE6 oi9nBASkj9UmkCwYqO0ISnPLD2nwBZzHyKQe+7HnMCm1KNof7dfVcsJ/WXaV2KYirpHb 1HN5p753zJFr24dixyWM6ySm/hPSyN9Q/35YCHSuu3PceBmBTe/blFIrT6UjLbYUjLod pAWUbtfDh287tEM1PLOseAuUCaZ26sK4DiwWietYtu1GXmApj6itkJ1BlFwNy/Bs2785 8/Ue5mWj1i60Gl5N7dyH8gXFxE5UEtnmrcbPZzwA9agrUVeZFHJMB0BgUAt185sBN060 4oxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=/TKXVn4MrjFnB/N7kOMPASVlz0pjQ3bjdfS3UyYGN0w=; b=KlWQgF2/RuSeANYIyrHl3U35nywkl1XTXt5gLonUuv0tsBBJBPzwWjnT3oNlhg04gt 0EQ1vBNHtdh7HRIHIhYI16SJZaGvP0tDC/Cl6r9zS5PhkHay/04wD/w/IY8jGQPuuJ2s iHhvAIVdLJ5w9CaXaTJ2SxFbXfX3MASMKD0IgPlekU0XtQriI8/VSoKnw3Zb3WNluT9B c7rIOReNAaNyEa91LTMs18J4OMvW0xqcRRMAGPkBuz6Zm9QFHtsfENrRQoMAhEt5iPUx zY13MwnbSIkYdBxLU74/jC3tMoFdeTmohjoKUYpdifjCnPDE1ocgITa8Upc0SKUJvxiv WnXg== 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=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l65-v6si6491607pge.672.2018.06.28.12.38.44; Thu, 28 Jun 2018 12:39:28 -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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S967616AbeF1RsS (ORCPT + 99 others); Thu, 28 Jun 2018 13:48:18 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:53232 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S966022AbeF1RsQ (ORCPT ); Thu, 28 Jun 2018 13:48:16 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 16D0540255D7; Thu, 28 Jun 2018 17:48:16 +0000 (UTC) Received: from localhost (unknown [10.18.25.149]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A5AD2213ED6A; Thu, 28 Jun 2018 17:48:15 +0000 (UTC) Date: Thu, 28 Jun 2018 13:48:15 -0400 From: Mike Snitzer To: "Kani, Toshi" Cc: "dan.j.williams@intel.com" , "ross.zwisler@linux.intel.com" , "dm-devel@redhat.com" , "linux-kernel@vger.kernel.org" , "linux-xfs@vger.kernel.org" , "linux-nvdimm@lists.01.org" , "stable@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" Subject: Re: [PATCH v3 1/3] pmem: only set QUEUE_FLAG_DAX for fsdax mode Message-ID: <20180628174815.GA18768@redhat.com> References: <20180626191346.GA7233@redhat.com> <1530046327.14039.273.camel@hpe.com> <1530048093.14039.286.camel@hpe.com> <1530048545.14039.288.camel@hpe.com> <20180626220430.GA4269@linux.intel.com> <1530207635.14039.308.camel@hpe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1530207635.14039.308.camel@hpe.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Thu, 28 Jun 2018 17:48:16 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Thu, 28 Jun 2018 17:48:16 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'msnitzer@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 28 2018 at 1:42pm -0400, Kani, Toshi wrote: > On Tue, 2018-06-26 at 16:04 -0600, Ross Zwisler wrote: > > On Tue, Jun 26, 2018 at 02:51:52PM -0700, Dan Williams wrote: > > > 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 > > > " > > > > Dan is correct that there is no user visible change for this. It is the right > > thing to do for consistency and sanity, but it doesn't actually have user > > visible behavior that needs to be backported to stable. > > > > Toshi is correct that this change is only for raw mode namespaces, not btt > > namespaces. > > > > I'll adjust the changelog and remove the stable flag for v5, and I'll add a > > Fixes: tag for patch 2. > > Hi Ross, > > Your patches look good. But I am still not clear about the Fixes & > stable handling. Talking about user visible behavior, I do not think we > had any issue until dax support was dropped from raw mode. Until then, > the pmem driver supported dax for all modes, and the check for > direct_access worked. I've staged the changes to send to Linus shortly. The first patch has: Fixes: 569d0365f571 ("dax: require 'struct page' by default for filesystem dax") Cc: stable@vger.kernel.org As that is the right thing to do given the other 2 patches are marked for stable. We don't want to have a stable kernel with the last 2 patches but not the first. Mike