Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp4328568imj; Tue, 12 Feb 2019 13:59:51 -0800 (PST) X-Google-Smtp-Source: AHgI3IZn79T4uiT/Gj+eFxnfDforRJ9GDJymTAbR5hVNHRMbFol95u3dtpiO/+D0+5PXmHh6ndPU X-Received: by 2002:a17:902:7204:: with SMTP id ba4mr6281912plb.186.1550008791274; Tue, 12 Feb 2019 13:59:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550008791; cv=none; d=google.com; s=arc-20160816; b=RS7i5T0zpJFkXTUThH6SjhsUu4FfuEXqwSX0JyYcCXL0mXmDgEkUcbk4OyVieIAD3l PSgYQ56AqzCkBcUByUm1VMcAVKwoJPG5QA3oKgpY7MT0zhV0OU4IllpwNiusSEP60WHp rva4+L03RsELUXtG2BHLofG05odVmG7DbKSpwMAnL4jdQp0SLgqwoPkzfso9uRIgZDnm L3At0qv3lhiIeaSfjnh8D2JF6peUnddgV3FJbY2vYp3TELFjpz9nrt+sid48q9OlIHjy kYKLPRaage7c3BfzyhLeyX+RQ+CTQ5XXBeFZXqm3KRYaTsM08ZWG4u56qNaQi2YxlRiE GX3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:message-id:date:cc:to:from:subject; bh=UszyriXwVi7h1+mT1jtgS8UCJBNZ3GARbrKzQb8gbkY=; b=SGC+jOw8tGH6jPcUqUx4lXmC1Mh9ZH9cGYeGhluFODs3jhFK5bEBIE+NYaroBiGeyl shbyb1Ge9HHfaP+3u/WMkKW6O1+d4qrhG6v8qpje9lwV9myPSz7pHfPdvTxN+d5tpUvQ mSwRJGWtBz/4CB6VMqenLJneqfQYohQTIZGY0lefqUqbWHMTtplLWbME8Hm4v9ruz3p3 tuz1/zrSy4K1dRIz/8QGGec8pq9T5rL7y6P4yzTdMpBfpyqFezc57p0pm67iy2jVRD+X TrtV00xR1Y0WSi4mj1doD36iXZKosHXROuPG00K3B7L54sV+1P1akVr/ocvz6+t9RAxA wDaA== 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 g28si3698709pgg.38.2019.02.12.13.59.35; Tue, 12 Feb 2019 13:59:51 -0800 (PST) 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 S1732525AbfBLVhX (ORCPT + 99 others); Tue, 12 Feb 2019 16:37:23 -0500 Received: from mga18.intel.com ([134.134.136.126]:36555 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727345AbfBLVhW (ORCPT ); Tue, 12 Feb 2019 16:37:22 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Feb 2019 13:37:18 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,362,1544515200"; d="scan'208";a="125954900" Received: from dwillia2-desk3.jf.intel.com (HELO dwillia2-desk3.amr.corp.intel.com) ([10.54.39.16]) by orsmga003.jf.intel.com with ESMTP; 12 Feb 2019 13:37:18 -0800 Subject: [PATCH 0/7] libnvdimm/pfn: Fix section-alignment padding From: Dan Williams To: linux-nvdimm@lists.01.org Cc: "Darrick J. Wong" , stable@vger.kernel.org, Jan Kara , Oliver O'Halloran , Jeff Moyer , Johannes Thumshirn , linux-kernel@vger.kernel.org, vishal.l.verma@intel.com, linux-fsdevel@vger.kernel.org Date: Tue, 12 Feb 2019 13:24:40 -0800 Message-ID: <155000668075.348031.9371497273408112600.stgit@dwillia2-desk3.amr.corp.intel.com> User-Agent: StGit/0.18-2-gc94f MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Lately Linux has encountered platforms that collide Persistent Memory regions between each other, specifically cases where ->start_pad needed to be non-zero. This lead to commit ae86cbfef381 "libnvdimm, pfn: Pad pfn namespaces relative to other regions". That commit allowed namespaces to be mapped with devm_memremap_pages(). However dax operations on those configurations currently fail if attempted within the ->start_pad range because pmem_device->data_offset was still relative to raw resource base not relative to the section aligned resource range mapped by devm_memremap_pages(). Luckily __bdev_dax_supported() caught these failures and simply disabled dax. However, to fix this situation a non-backwards compatible change needs to be made to the interpretation of the nd_pfn info-block. ->start_pad needs to be accounted in ->map.map_offset (formerly ->data_offset), and ->map.map_base (formerly ->phys_addr) needs to be adjusted to the section aligned resource base used to establish ->map.map formerly (formerly ->virt_addr). See patch 7 "libnvdimm/pfn: Fix 'start_pad' implementation" for more details, and the ndctl patch series "Improve support + testing for labels + info-blocks" for the corresponding regression test. --- Dan Williams (7): libnvdimm/pfn: Account for PAGE_SIZE > info-block-size in nd_pfn_init() libnvdimm/pmem: Honor force_raw for legacy pmem regions dax: Check the end of the block-device capacity with dax_direct_access() libnvdimm/pfn: Introduce super-block minimum version requirements libnvdimm/pfn: Remove dax_label_reserve libnvdimm/pfn: Introduce 'struct pfn_map_info' libnvdimm/pfn: Fix 'start_pad' implementation drivers/dax/pmem.c | 9 +- drivers/dax/super.c | 39 ++++++-- drivers/nvdimm/namespace_devs.c | 4 + drivers/nvdimm/nd.h | 15 +++ drivers/nvdimm/pfn.h | 4 + drivers/nvdimm/pfn_devs.c | 181 ++++++++++++++++++++++++++++----------- drivers/nvdimm/pmem.c | 111 +++++++++++------------- drivers/nvdimm/pmem.h | 12 --- tools/testing/nvdimm/pmem-dax.c | 15 ++- 9 files changed, 244 insertions(+), 146 deletions(-)