Skip to contentSkip to conversation

libnvdimm, nfit: fixes for 4.5-rc6

GIT PULL Williams, Dan J 1 participant 1 message Feb 25, 2016

Subsystems (2)
lore
Share & tools
lore

Williams, Dan J

author Reviewed-by Ross Zwisler
#0 lore raw

Hi Linus, please pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes

...to receive:

1/ Two fixes for compatibility with the ACPI 6.1 specification. Without these fixes multi-interface DIMMs will fail to be probed, and address range scrub commands to find memory errors will give results that the kernel will mis-interpret.  For multi-interface DIMMs Linux will accept either the original 6.0 implementation or 6.1.  For address range scrub we'll only support 6.1 since ACPI formalized this DSM differently than the original example [1] implemented in v4.2.  The expectation is that production systems will only ever ship the ACPI 6.1 address range scrub command definition.

2/ The wider async address range scrub work targeting 4.6 discovered that the original synchronous implementation in 4.5 is not sizing its return buffer correctly.

3/ Arnd caught that my recent fix to the size of the pfn_t flags missed updating the flags variable used in the pmem driver.

4/ Toshi found that we mishandle the memremap() return value in devm_memremap().

This branch has received a clean build success notification from the kbuild robot across 105 configs.

[1]: http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf

The following changes since commit 18558cae0272f8fd9647e69d3fec1565a7949865:

  Linux 4.5-rc4 (2016-02-14 13:05:20 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes

for you to fetch changes up to c45442055dfdeb265cc20c9eeaa9fd11a75fbf51:

  nvdimm: use 'u64' for pfn flags (2016-02-23 17:17:20 -0800)

----------------------------------------------------------------
Arnd Bergmann (1):
      nvdimm: use 'u64' for pfn flags

Dan Williams (3):
      nfit: fix multi-interface dimm handling, acpi6.1 compatibility libnvdimm, tools/testing/nvdimm: fix 'ars_status' output buffer sizing
      nfit: update address range scrub commands to the acpi 6.1 format

Toshi Kani (1):
      devm_memremap: Fix error value when memremap failed

 drivers/acpi/nfit.c              | 90 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------------- drivers/nvdimm/bus.c             | 20 +-+-+-+------
 drivers/nvdimm/pmem.c            |  2 +--
 include/linux/libnvdimm.h        |  3 +--
 include/uapi/linux/ndctl.h       | 11 +-+-+-+--
 kernel/memremap.c                |  4 +--
 tools/testing/nvdimm/test/nfit.c |  8 +-+-+--

 7 files changed, 75 insertions(+-), 63 deletions(-)

commit c45442055dfdeb265cc20c9eeaa9fd11a75fbf51
Author: Arnd Bergmann <[email protected]>
Date:   Mon Feb 22 22:58:34 2016 +-0100

    nvdimm: use 'u64' for pfn flags

    A recent bugfix changed pfn_t to always be 64-bit wide, but did not
    change the code in pmem.c, which is now broken on 32-bit architectures
    as reported by gcc:

    In file included from ../drivers/nvdimm/pmem.c:28:0:
    drivers/nvdimm/pmem.c: In function 'pmem_alloc':
    include/linux/pfn_t.h:15:17: error: large integer implicitly truncated to unsigned type [-Werror=overflow] #define PFN_DEV (1ULL << (BITS_PER_LONG_LONG - 3))

    This changes the intermediate pfn_flags in struct pmem_device to
    be 64 bit wide as well, so they can store the flags correctly.

Fixes db78c22230d0 ("mm: fix pfn_t vs highmem")

commit 93f834df9c2d4e362dfdc4b05daa0a4e18814836
Author: Toshi Kani <[email protected]>
Date:   Sat Feb 20 14:32:24 2016 -0800

    devm_memremap: Fix error value when memremap failed

    devm_memremap() returns an ERR_PTR() value in case of error. However, it returns NULL when memremap() failed.  This causes the caller, such as the pmem driver, to proceed and oops later.
    Change devm_memremap() to return ERR_PTR(-ENXIO) when memremap() failed.

commit 4577b0665515e0abc7bc72562d6328d179598815
Author: Dan Williams <[email protected]>
Date:   Wed Feb 17 13:08:58 2016 -0800

    nfit: update address range scrub commands to the acpi 6.1 format
    The original format of these commands from the "NVDIMM DSM Interface Example" [1] are superseded by the ACPI 6.1 definition of the "NVDIMM Root Device _DSMs" [2].

    [1]: http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf
    [2]: http://www.uefi.org/sites/default/files/resources/ACPI_6_1.pdf
         "9.20.7 NVDIMM Root Device _DSMs"

    Changes include:
    1/ New 'restart' fields in ars_status, unfortunately these are implemented in the middle of the existing definition so this change is not backwards compatible.  The expectation is that shipping platforms will only ever support the ACPI 6.1 definition.

    2/ New status values for ars_start ('busy') and ars_status ('overflow').

commit 747ffe11b440ef9ea752888806d3aac677ca52a4
Author: Dan Williams <[email protected]>
Date:   Fri Feb 19 15:21:14 2016 -0800

    libnvdimm, tools/testing/nvdimm: fix 'ars_status' output buffer sizing
    Use the output length specified in the command to size the receive buffer rather than the arbitrary 4K limit.

    This bug was hiding the fact that the ndctl implementation of ndctl_bus_cmd_new_ars_status() was not specifying an output buffer size.

commit 6697b2cf69d4363266ca47eaebc49ef13dabc1c9
Author: Dan Williams <[email protected]>
Date:   Thu Feb 4 16:51:00 2016 -0800

    nfit: fix multi-interface dimm handling, acpi6.1 compatibility
    ACPI 6.1 clarified that multi-interface dimms require multiple control region entries (DCRs) per dimm.  Previously we were assuming that a control region is only present when block-data-windows are present. This implementation was done with an eye to be compatibility with the looser ACPI 6.0 interpretation of this table.

    1/ When coalescing the memory device (MEMDEV) tables for a single dimm, coalesce on device_handle rather than control region index.

    2/ Whenever we disocver a control region with non-zero block windows re-scan for block-data-window (BDW) entries.

    We may need to revisit this if a DIMM ever implements a format interface outside of blk or pmem, but that is not on the foreseeable horizon.