[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <158291746615.1609624.7591692546429050845.stgit@dwillia2-desk3.amr.corp.intel.com>
Date: Fri, 28 Feb 2020 11:17:46 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: linux-nvdimm@...ts.01.org
Cc: Oliver O'Halloran <oohall@...il.com>,
Vishal Verma <vishal.l.verma@...el.com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>,
Jeff Moyer <jmoyer@...hat.com>,
"Aneesh Kumar K.V" <aneesh.kumar@...ux.ibm.com>,
linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org
Subject: [PATCH v3 0/5] libnvdimm: Cross-arch compatible namespace alignment
Changes since v2 [1]:
- Fix up a missing space in flags_show() (Jeff)
- Prompted by Jeff saying that v2 only worked for him if
memremap_compat_align() returned PAGE_SIZE (which defeats the purpose)
I developed a new ndctl unit test that runs through the possible
legacy configurations that the kernel needs to support. Several changes
fell out as a result:
- Update nd_pfn_validate() to add more -EOPNOTSUPP cases. That error
code indicates "Stop, the pfn looks coherent, but invalid. Do not
proceed with exposing a raw namespace, require the user to
investigate whether the infoblock needs to be rewritten, or the
kernel configuration (like PAGE_SIZE) needs to change."
- Move the validation of fsdax and devdax infoblocks to
nd_pfn_validate() so that the presence of non-zero 'start_pad' and
'end_trunc' can be considered in the alignment validation.
- Fail namespace creation when the base address is misaligned. A
non-zero-start_pad prevents dax operation due to original bug of
->data_offset being base address relative when it should have been
->start_pad relative. So, reject all base address misaligned
namespaces in nd_pfn_init().
[1]: http://lore.kernel.org/r/158155489850.3343782.2687127373754434980.stgit@dwillia2-desk3.amr.corp.intel.com
---
Review / merge logistics notes:
Patch "libnvdimm/namespace: Enforce memremap_compat_align()" has
changed enough that it needs to be reviewed again.
Patch "mm/memremap_pages: Introduce memremap_compat_align()" still
needs a PowerPC maintainer ack for the touches to
arch/powerpc/mm/ioremap.c.
---
Aneesh reports that PowerPC requires 16MiB alignment for the address
range passed to devm_memremap_pages(), and Jeff reports that it is
possible to create a misaligned namespace which blocks future namespace
creation in that region. Both of these issues require namespace
alignment to be managed at the region level rather than padding at the
namespace level which has been a broken approach to date.
Introduce memremap_compat_align() to indicate the hard requirements of
an arch's memremap_pages() implementation. Use the maximum known
memremap_compat_align() to set the default namespace alignment for
libnvdimm. Consult that alignment when allocating free space. Finally,
allow the default region alignment to be overridden to maintain the same
namespace creation capability as previous kernels.
The ndctl unit tests, which have some misaligned namespace assumptions,
are updated to use the alignment override where necessary.
Thanks to Aneesh for early feedback and testing on this improved
alignment handling.
---
Dan Williams (5):
mm/memremap_pages: Introduce memremap_compat_align()
libnvdimm/pfn: Prevent raw mode fallback if pfn-infoblock valid
libnvdimm/namespace: Enforce memremap_compat_align()
libnvdimm/region: Introduce NDD_LABELING
libnvdimm/region: Introduce an 'align' attribute
arch/powerpc/Kconfig | 1
arch/powerpc/mm/ioremap.c | 21 +++++
arch/powerpc/platforms/pseries/papr_scm.c | 2
drivers/acpi/nfit/core.c | 4 +
drivers/nvdimm/dimm.c | 2
drivers/nvdimm/dimm_devs.c | 95 +++++++++++++++++----
drivers/nvdimm/namespace_devs.c | 23 ++++-
drivers/nvdimm/nd.h | 3 -
drivers/nvdimm/pfn_devs.c | 34 ++++++-
drivers/nvdimm/region_devs.c | 132 ++++++++++++++++++++++++++---
include/linux/libnvdimm.h | 2
include/linux/memremap.h | 8 ++
include/linux/mmzone.h | 1
lib/Kconfig | 3 +
mm/memremap.c | 23 +++++
15 files changed, 307 insertions(+), 47 deletions(-)
base-commit: 11a48a5a18c63fd7621bb050228cebf13566e4d8
Powered by blists - more mailing lists