Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp5587106imm; Tue, 26 Jun 2018 14:04:06 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfVTISGWh29Bvw2+4drNEiv+m5mMT4eZvs9L0rNhhyxPLwNVsDWa0TEGkmI381Z0OYZPqNR X-Received: by 2002:a62:41d6:: with SMTP id g83-v6mr2987189pfd.219.1530047046495; Tue, 26 Jun 2018 14:04:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530047046; cv=none; d=google.com; s=arc-20160816; b=iairhAKuYOrXXanztXDBZ0Byfbpv0TjdVZQZBmC47Z/Sriztd9D3immtEUuBUJrDtJ XOqh8yScFNO+ymXN+SM+ONK5EJ+Qgj+IlqBsN3AxEtlMEpw2Bho8s1LKoKCClJztgH0r OKDw+3GnCSd+8QNRjvMiq9VJllbdkR/4CW46yF6rSXx8ngJAciX4CSzg0+7SIO6RhwNO dlNRPF+anjYbiNpi0ygcRLzHUBnO4F+i/+9iYgRlccZIQJwBtHeU17G0k17pa82RHue4 VgYLQ2a8oCOqAAHUukg75WPKD0jwoYmWsHOVTCmBAwsPPt+q5vm5U9ZH1SueLXejCzw2 BoOA== 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=IAJPa+OU7AIGrfjl+Oq9ZKgb4EiXMMKIS99pIQgUfxk=; b=g2UbeIjGOQV4CzDsjEodL3qGSOQYKlO3s+WrLCqIKyictRxv9oDKExuh2pjiaTUdSH vbzsxLLB+9ryOoxFz0Jpdg6GDeyT6sdYUNVGIvW83e8P5oTyBwF2xIPUxJCg1XuUqXUl TdnhT9EdxTqEsc4EdnG17h4I7+0iGdBpieuzQzHKzengcBmymPeBxiGM2vq8wRTWQwOX T83xLfn61ZcuNpozQHW/ODtuMsAAG8twrOLSGGVpNWyNFiasBWv/hg9Vfc2jwaape+av CeMVB1LpaEgdHE0hCIGssnW62kdyVeTRr3JQmQ9pQJhaIz6yNPE1YgIBCPIpVDbwWgwg GRvA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=YrJOfyPc; 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 r21-v6si1942588pgu.55.2018.06.26.14.03.51; Tue, 26 Jun 2018 14:04:06 -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=YrJOfyPc; 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 S1751054AbeFZVDD (ORCPT + 99 others); Tue, 26 Jun 2018 17:03:03 -0400 Received: from mail-oi0-f67.google.com ([209.85.218.67]:39826 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750932AbeFZVDB (ORCPT ); Tue, 26 Jun 2018 17:03:01 -0400 Received: by mail-oi0-f67.google.com with SMTP id 18-v6so7840831oiq.6 for ; Tue, 26 Jun 2018 14:03:01 -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=IAJPa+OU7AIGrfjl+Oq9ZKgb4EiXMMKIS99pIQgUfxk=; b=YrJOfyPcOTDLoE5geFjUSGqwaJTjIVtZKhsAwZDFVywE6qLuSkaDK/aW6Y4u+nB7PB WCzwgThHfpo/lmvxC6qShj3RlYZMD8PzE/njZleZfIUtAGEWDMs3GP2FIAw2kqnd9Bl1 gL2xMNNHoSXi2EhVBvEjBoVrwfvB5X55Zcph0yGY+bxuTsD1c4JNl2DIBHQvtWBRWn4A cuPkzUI7tIWkEU/7QVPgfJllNtyYlRhUQAgoUdJ2h1hxFt4ZTEZNzVlHfZGw8f6j220N i27V59YXUEkyo4rnT3UfxzTU+s/txEohWVaglwld4OVy+aRWzHJZyuHfHili6Sm8Snye uVlQ== 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=IAJPa+OU7AIGrfjl+Oq9ZKgb4EiXMMKIS99pIQgUfxk=; b=P5fr6cnK7GHo79NzWYQ1gJHUIzruPe9wKYJJ1A4pSNyvLpxFK6K5ZqyRrjZCg5w2uB EqQcweSiqeVxcmmYonU0sob9ynvRVUXvZnv3Sv+Y/HqQLfwnRvlhDfy/SM3cHeoyVVHg ak9P36FetDd8wErMB4khFbF2gR/QlAASa7DqbqqV/2GP/7KfMQCQb1m9LuwVO7EnvxkD upv+CFHAco7UR7TA7VOXH943ryY/QNg9EcZG4nYy9QVxwoN0fsFkE+g9kuaUGUmb4mi7 NTM5WoKmSPGns+Z1Xvz8wQ8sSdM8tFNx1P4ta6+YMVT11HJiQATzP37CTVblKnbxEDSw OFvg== X-Gm-Message-State: APt69E0AlQODUnS4rDTK/nveAZASe5dfDh0H2e4lGwLFTU18ETuLoVAT 1kzY+2X8AqV/nyeXX++sqyNaRqTxuxVGFZ2CPiF0DQ== X-Received: by 2002:aca:745:: with SMTP id 66-v6mr1657836oih.295.1530046980739; Tue, 26 Jun 2018 14:03:00 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:38c2:0:0:0:0:0 with HTTP; Tue, 26 Jun 2018 14:02:59 -0700 (PDT) In-Reply-To: <1530046327.14039.273.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> From: Dan Williams Date: Tue, 26 Jun 2018 14:02:59 -0700 Message-ID: Subject: Re: [PATCH v3 1/3] pmem: only set QUEUE_FLAG_DAX for fsdax mode To: "Kani, Toshi" Cc: "snitzer@redhat.com" , "dm-devel@redhat.com" , "ross.zwisler@linux.intel.com" , "linux-nvdimm@lists.01.org" , "linux-kernel@vger.kernel.org" , "stable@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-xfs@vger.kernel.org" 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 1:54 PM, Kani, Toshi wrote: > On Tue, 2018-06-26 at 15:13 -0400, Mike Snitzer wrote: >> On Tue, Jun 26 2018 at 3:07pm -0400, >> Dan Williams wrote: >> >> > On Tue, Jun 26, 2018 at 11:58 AM, Mike Snitzer wrote: >> > > On Tue, Jun 26 2018 at 2:52pm -0400, >> > > Dan Williams wrote: >> > > >> > > > On Tue, Jun 26, 2018 at 10:59 AM, Ross Zwisler >> > > > wrote: >> > > > > QUEUE_FLAG_DAX is an indication that a given block device supports >> > > > > filesystem DAX and should not be set for PMEM namespaces which are in "raw" >> > > > > or "sector" modes. These namespaces lack struct page and are prevented >> > > > > from participating in filesystem DAX. >> > > > > >> > > > > Signed-off-by: Ross Zwisler >> > > > > Suggested-by: Mike Snitzer >> > > > > Cc: stable@vger.kernel.org >> > > > >> > > > Why is this cc: stable? What is the user visible impact of this change >> > > > especially given the requirement to validate QUEUE_FLAG_DAX with >> > > > bdev_dax_supported()? Patch looks good, but it's just a cosmetic fixup >> > > > afaics. >> > > >> > > This isn't cosmetic when you consider that stacking up a DM device is >> > > looking at this flag to determine whether a table does or does _not_ >> > > support DAX. >> > > >> > > So this patch, in conjunction with the other changes in the series, is >> > > certainly something I'd consider appropriate for stable. >> > >> > I think this classifies as something that never worked correctly and >> > is not a regression. It does not identify which commit it is repairing >> > or the user visible failure mode. >> >> So you're taking issue with making stacked dax configs work in older >> kernels? That's fine. We can drop the stable cc if you like. >> >> But I mean we intended for this to work.. so the Fixes commit references >> can easily be added, e.g.: 545ed20e6df68a4d2584a29a2a28ee8b2f7e9547 >> ("dm: add infrastructure for DAX support") > > 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.