libnvdimm fixes for 4.7-rc6
Subsystems (2)
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 <[email protected]>
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.
commit 4995734e973a2c2e9c6f6413cbad9913fc4df0dc
Author: Dan Williams <[email protected]>
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.
commit 023954351fae0e34ba247cff4d798c98290b20a4
Author: Eric Sandeen <[email protected]>
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 <[email protected]> Signed-off-by: Dan Williams <[email protected]>
commit 1bcbf42d2732b3fdaa8559b0dfc91567769e23c8
Author: Dan Williams <[email protected]>
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.