[GIT PULL] libnvdimm fixes for 4.7-rc6

* [GIT PULL] libnvdimm fixes for 4.7-rc6
@ 2016-07-01  1:01 Williams, Dan J
  0 siblings, 0 replies; 6+ messages in thread
From: Williams, Dan J @ 2016-07-01  1:01 UTC (permalink / raw)
  To: torvalds; +Cc: linux-kernel, linux-nvdimm, linux-acpi, linux-fsdevel

Hi Linus, please pull from:

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

...to receive:

1/ Two regression fixes since v4.6:  one for the byte order of a sysfs
attribute (bz121161) and another for QEMU 2.6's NVDIMM _DSM (ACPI
Device Specific Method) implementation that gets tripped up by new
auto-probing behavior in the NFIT driver.

2/ A fix tagged for -stable that stops the kernel from
clobbering/ignoring changes to the configuration of a 'pfn' instance
("struct page" driver).  For example changing the alignment from 2M to
1G may silently revert to 2M if that value is currently stored on
media.

3/ A fix from Eric for an xfstests failure in dax.  It is not currently
tagged for -stable since it requires an 8-exabyte file system to
trigger, and there appear to be no user visible side effects.

The following changes since commit 33688abb2802ff3a230bd2441f765477b94cc89e:

  Linux 4.7-rc4 (2016-06-19 21:30:02 -0700)

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 1bcbf42d2732b3fdaa8559b0dfc91567769e23c8:

  nfit: fix format interface code byte order (2016-06-29 11:19:32 -0700)

----------------------------------------------------------------
Dan Williams (3):
      libnvdimm, pfn, dax: fix initialization vs autodetect for mode + alignment
      acpi, nfit: fix acpi_check_dsm() vs zero functions implemented
      nfit: fix format interface code byte order

Eric Sandeen (1):
      dax: fix offset overflow in dax_io

 drivers/acpi/nfit.c       | 12 +++++------
 drivers/acpi/nfit.h       | 10 +++++-----
 drivers/acpi/utils.c      |  6 +++---
 drivers/nvdimm/pfn_devs.c | 51 +++++++++++++++++++++++++++++++++++++----------
 fs/dax.c                  |  7 ++++++-
 5 files changed, 60 insertions(+), 26 deletions(-)

commit 1ee6667cd8d183b2fed12f97285f184431d2caf9
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Thu Jun 23 17:50:39 2016 -0700

    libnvdimm, pfn, dax: fix initialization vs autodetect for mode + alignment

    The updated ndctl unit tests discovered that if a pfn configuration with
    a 4K alignment is read from the namespace, that alignment will be
    ignored in favor of the default 2M alignment.  The result is that the
    configuration will fail initialization with a message like:

        dax6.1: bad offset: 0x22000 dax disabled align: 0x200000

    Fix this by allowing the alignment read from the info block to override
    the default which is 2M not 0 in the autodetect path.  This also fixes a
    similar problem with the mode and alignment settings silently being
    overwritten by the kernel when userspace has changed it.  We now will
    either overwrite the info block if userspace changes the uuid or fail
    and warn if a live setting disagrees with the info block.

    Cc: <stable@vger.kernel.org>
    Cc: Micah Parrish <micah.parrish@hpe.com>
    Cc: Toshi Kani <toshi.kani@hpe.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

commit 4995734e973a2c2e9c6f6413cbad9913fc4df0dc
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Fri Jun 24 09:07:39 2016 -0700

    acpi, nfit: fix acpi_check_dsm() vs zero functions implemented

    QEMU 2.6 implements nascent support for nvdimm DSMs. Depending on
    configuration it may only implement the function0 dsm to indicate that
    no other DSMs are available. Commit 31eca76ba2fc "nfit, libnvdimm:
    limited/whitelisted dimm command marshaling mechanism" breaks QEMU, but
    QEMU is spec compliant.  Per the spec the way to indicate that no
    functions are supported is:

        If Function Index is zero, the return is a buffer containing one bit
        for each function index, starting with zero. Bit 0 indicates whether
        there is support for any functions other than function 0 for the
        specified UUID and Revision ID. If set to zero, no functions are
        supported (other than function zero) for the specified UUID and
        Revision ID.

    Update the nfit driver to determine the family (interface UUID) without
    requiring the implementation to define any other functions, i.e.
    short-circuit acpi_check_dsm() to succeed per the spec.  The nfit driver
    appears to be the only user passing funcs==0 to acpi_check_dsm(), so
    this behavior change of the common routine should be limited to the
    probing done by the nfit driver.

    Cc: Len Brown <lenb@kernel.org>
    Cc: Jerry Hoemann <jerry.hoemann@hpe.com>
    Acked-by: "Rafael J. Wysocki" <rafael@kernel.org>
    Fixes: 31eca76ba2fc ("nfit, libnvdimm: limited/whitelisted dimm command marshaling mechanism")
    Reported-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>
    Tested-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

commit 023954351fae0e34ba247cff4d798c98290b20a4
Author: Eric Sandeen <sandeen@redhat.com>
Date:   Thu Jun 23 16:54:46 2016 -0500

    dax: fix offset overflow in dax_io

    This isn't functionally apparent for some reason, but
    when we test io at extreme offsets at the end of the loff_t
    rang, such as in fstests xfs/071, the calculation of
    "max" in dax_io() can be wrong due to pos + size overflowing.

    For example,

    # xfs_io -c "pwrite 9223372036854771712 512" /mnt/test/file

    enters dax_io with:

    start 0x7ffffffffffff000
    end   0x7ffffffffffff200

    and the rounded up "size" variable is 0x1000.  This yields:

    pos + size 0x8000000000000000 (overflows loff_t)
           end 0x7ffffffffffff200

    Due to the overflow, the min() function picks the wrong
    value for the "max" variable, and when we send (max - pos)
    into i.e. copy_from_iter_pmem() it is also the wrong value.

    This somehow(tm) gets magically absorbed without incident,
    probably because iter->count is correct.  But it seems best
    to fix it up properly by comparing the two values as
    unsigned.

    Signed-off-by: Eric Sandeen <sandeen@redhat.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

commit 1bcbf42d2732b3fdaa8559b0dfc91567769e23c8
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Wed Jun 29 11:19:32 2016 -0700

    nfit: fix format interface code byte order

    Per JEDEC Annex L Release 3 the SPD data is:

    Bits 9~5 00 000 = Function Undefined
             00 001 = Byte addressable energy backed
             00 010 = Block addressed
             00 011 = Byte addressable, no energy backed
             All other codes reserved
    Bits 4~0 0 0000 = Proprietary interface
             0 0001 = Standard interface 1
             All other codes reserved; see Definitions of Functions

    ...and per the ACPI 6.1 spec:

        byte0: Bits 4~0 (0 or 1)
        byte1: Bits 9~5 (1, 2, or 3)

    ...so a format interface code displayed as 0x301 should be stored in the
    nfit as (0x1, 0x3), little-endian.

    Cc: Toshi Kani <toshi.kani@hpe.com>
    Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
    Cc: Robert Moore <robert.moore@intel.com>
    Cc: Robert Elliott <elliott@hpe.com>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=121161
    Fixes: 30ec5fd464d5 ("nfit: fix format interface code byte order per ACPI6.1")
    Fixes: 5ad9a7fde07a ("acpi/nfit: Update nfit driver to comply with ACPI 6.1")
    Reported-by: Kristin Jacque <kristin.jacque@intel.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>

^ permalink raw reply	[flat|nested] 6+ messages in thread