| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <1494624947.21094.31.camel@intel.com>
Date: Fri, 12 May 2017 21:35:49 +0000
From: "Williams, Dan J" <dan.j.williams@...el.com>
To: "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>
Subject: [GIT PULL] libnvdimm fixes for 4.12-rc1
Hi Linus, please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes
...to receive some incremental fixes and a small feature addition
relative to the libnvdimm 4.12 pull request.
* Geert noticed that tinyconfig was bloated by BLOCK selecting DAX. The
size regression is fixed by moving all dax helpers into the dax-core
and only specifying "select DAX" for FS_DAX and dax-capable drivers. He
also asked for clarification of the NR_DEV_DAX config option which, on
closer look, does not need to be a config option at all. Mike also
throws in a DEV_DAX_PMEM fixup for good measure.
* Ben's attention to detail on -stable patch submissions caught a case
where the recent fixes to arch_copy_from_iter_pmem() missed a condition
where we strand dirty data in the cache. This is tagged for -stable and
will also be included in the rework of the pmem api to a proposed
{memcpy,copy_user}_flushcache() interface for 4.13.
* Vishal adds a feature that missed the initial pull due to pending
review feedback. It allows the kernel to clear media errors when
initializing a BTT (atomic sector update driver) instance on a pmem
namespace.
* Ross noticed that the dax_device + dax_operations conversion broke
__dax_zero_page_range(). The nvdimm unit tests fail to check this path,
but xfstests immediately trips over it. No excuse for missing this
before submitting the 4.12 pull request.
These all pass the nvdimm unit tests and an xfstests spot check. The
set has received a build success notification from the kbuild robot.
---
The following changes since commit 736163671bcb163fc82600b46c83dfa89d532d95:
Merge branch 'for-4.12/dax' into libnvdimm-for-next (2017-05-04 23:38:43 -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 e84b83b9ee2187817cf895471675f1ccdf64cd53:
filesystem-dax: fix broken __dax_zero_page_range() conversion (2017-05-10 21:46:55 -0700)
----------------------------------------------------------------
Ben Hutchings (1):
x86, pmem: Fix cache flushing for iovec write < 8 bytes
Dan Williams (3):
block, dax: move "select DAX" from BLOCK to FS_DAX
device-dax: kill NR_DEV_DAX
filesystem-dax: fix broken __dax_zero_page_range() conversion
Mike Galbraith (1):
device-dax: Tell kbuild DEV_DAX_PMEM depends on DEV_DAX
Vishal Verma (2):
libnvdimm: add an atomic vs process context flag to rw_bytes
libnvdimm, btt: ensure that initializing metadata clears poison
arch/x86/include/asm/pmem.h | 2 +-
block/Kconfig | 1 -
drivers/dax/Kconfig | 7 +--
drivers/dax/super.c | 81 +++++++++++++++++++++++++++---
drivers/nvdimm/blk.c | 3 +-
drivers/nvdimm/btt.c | 119 ++++++++++++++++++++++++++++++--------------
drivers/nvdimm/btt_devs.c | 2 +-
drivers/nvdimm/claim.c | 6 ++-
drivers/nvdimm/nd.h | 1 +
drivers/nvdimm/pfn_devs.c | 4 +-
fs/Kconfig | 1 +
fs/block_dev.c | 66 ------------------------
fs/dax.c | 4 +-
fs/ext2/super.c | 1 +
fs/ext4/super.c | 1 +
fs/xfs/xfs_super.c | 1 +
include/linux/blkdev.h | 2 -
include/linux/dax.h | 30 ++++++++++-
include/linux/nd.h | 12 +++--
19 files changed, 208 insertions(+), 136 deletions(-)
commit 74d71a01abef37f71d914f2105a4cb8712a2beb8
Author: Mike Galbraith <efault@....de>
Date: Sat May 6 06:14:43 2017 +0200
device-dax: Tell kbuild DEV_DAX_PMEM depends on DEV_DAX
ERROR: "devm_create_dev_dax" [drivers/dax/dax_pmem.ko] undefined!
ERROR: "alloc_dax_region" [drivers/dax/dax_pmem.ko] undefined!
ERROR: "dax_region_put" [drivers/dax/dax_pmem.ko] undefined!
Signed-off-by: Mike Galbraith <efault@....de>
Signed-off-by: Dan Williams <dan.j.williams@...el.com>
commit ef51042472f55b325fd7f2b26a2e29fd89757234
Author: Dan Williams <dan.j.williams@...el.com>
Date: Mon May 8 10:55:27 2017 -0700
block, dax: move "select DAX" from BLOCK to FS_DAX
For configurations that do not enable DAX filesystems or drivers, do not
require the DAX core to be built.
Given that the 'direct_access' method has been removed from
'block_device_operations', we can also go ahead and remove the
block-related dax helper functions from fs/block_dev.c to
drivers/dax/super.c. This keeps dax details out of the block layer and
lets the DAX core be built as a module in the FS_DAX=n case.
Filesystems need to include dax.h to call bdev_dax_supported().
Cc: linux-xfs@...r.kernel.org
Cc: Jens Axboe <axboe@...nel.dk>
Cc: "Theodore Ts'o" <tytso@....edu>
Cc: Matthew Wilcox <mawilcox@...rosoft.com>
Cc: Alexander Viro <viro@...iv.linux.org.uk>
Cc: "Darrick J. Wong" <darrick.wong@...cle.com>
Cc: Ross Zwisler <ross.zwisler@...ux.intel.com>
Reviewed-by: Jan Kara <jack@...e.com>
Reported-by: Geert Uytterhoeven <geert@...ux-m68k.org>
Signed-off-by: Dan Williams <dan.j.williams@...el.com>
commit cf1e22891bee39f50e058bee0827086fd75a8717
Author: Dan Williams <dan.j.williams@...el.com>
Date: Mon May 8 12:33:53 2017 -0700
device-dax: kill NR_DEV_DAX
There is no point to ask how many device-dax instances the kernel should
support. Since we are already using a dynamic major number, just allow
the max number of minors by default and be done. This also fixes the
fact that the proposed max for the NR_DEV_DAX range was larger than what
could be supported by alloc_chrdev_region().
Fixes: ba09c01d2fa8 ("dax: convert to the cdev api")
Reported-by: Geert Uytterhoeven <geert@...ux-m68k.org>
Tested-by: Geert Uytterhoeven <geert@...ux-m68k.org>
Signed-off-by: Dan Williams <dan.j.williams@...el.com>
commit 8376efd31d3d7c44bd05be337adde023cc531fa1
Author: Ben Hutchings <ben.hutchings@...ethink.co.uk>
Date: Tue May 9 18:00:43 2017 +0100
x86, pmem: Fix cache flushing for iovec write < 8 bytes
Commit 11e63f6d920d added cache flushing for unaligned writes from an
iovec, covering the first and last cache line of a >= 8 byte write and
the first cache line of a < 8 byte write. But an unaligned write of
2-7 bytes can still cover two cache lines, so make sure we flush both
in that case.
Cc: <stable@...r.kernel.org>
Fixes: 11e63f6d920d ("x86, pmem: fix broken __copy_user_nocache ...")
Signed-off-by: Ben Hutchings <ben.hutchings@...ethink.co.uk>
Signed-off-by: Dan Williams <dan.j.williams@...el.com>
commit 3ae3d67ba705c754a3c91ac009f9ce73a0e7286a
Author: Vishal Verma <vishal.l.verma@...el.com>
Date: Wed May 10 15:01:30 2017 -0600
libnvdimm: add an atomic vs process context flag to rw_bytes
nsio_rw_bytes can clear media errors, but this cannot be done while we
are in an atomic context due to locking within ACPI. From the BTT,
->rw_bytes may be called either from atomic or process context depending
on whether the calls happen during initialization or during IO.
During init, we want to ensure error clearing happens, and the flag
marking process context allows nsio_rw_bytes to do that. When called
during IO, we're in atomic context, and error clearing can be skipped.
Cc: Dan Williams <dan.j.williams@...el.com>
Signed-off-by: Vishal Verma <vishal.l.verma@...el.com>
Signed-off-by: Dan Williams <dan.j.williams@...el.com>
commit b177fe85dd27de1ee4c29f59c4e82b3ea3b78784
Author: Vishal Verma <vishal.l.verma@...el.com>
Date: Wed May 10 15:01:31 2017 -0600
libnvdimm, btt: ensure that initializing metadata clears poison
If we had badblocks/poison in the metadata area of a BTT, recreating the
BTT would not clear the poison in all cases, notably the flog area. This
is because rw_bytes will only clear errors if the request being sent
down is 512B aligned and sized.
Make sure that when writing the map and info blocks, the rw_bytes being
sent are of the correct size/alignment. For the flog, instead of doing
the smaller log_entry writes only, first do a 'wipe' of the entire area
by writing zeroes in large enough chunks so that errors get cleared.
Cc: Andy Rudoff <andy.rudoff@...el.com>
Cc: Dan Williams <dan.j.williams@...el.com>
Signed-off-by: Vishal Verma <vishal.l.verma@...el.com>
Signed-off-by: Dan Williams <dan.j.williams@...el.com>
commit e84b83b9ee2187817cf895471675f1ccdf64cd53
Author: Dan Williams <dan.j.williams@...el.com>
Date: Wed May 10 19:38:13 2017 -0700
filesystem-dax: fix broken __dax_zero_page_range() conversion
The conversion of __dax_zero_page_range() to 'struct dax_operations'
caused it to frequently fail. The mistake was treating the @size
parameter as a dax mapping length rather than just a length of the
clear_pmem() operation. The dax mapping length is assumed to be hard
coded as PAGE_SIZE.
Without this fix any page unaligned zeroing request will trigger a
-EINVAL return from bdev_dax_pgoff().
Cc: Jan Kara <jack@...e.com>
Cc: Christoph Hellwig <hch@....de>
Reported-by: Ross Zwisler <ross.zwisler@...ux.intel.com>
Tested-by: Ross Zwisler <ross.zwisler@...ux.intel.com>
Fixes: cccbce671582 ("filesystem-dax: convert to dax_direct_access()")
Signed-off-by: Dan Williams <dan.j.williams@...el.com>
Powered by blists - more mailing lists