[ndctl PATCH] ndctl: remove %defattr from spec file template
by Dan Williams
Per Ralf Corsepius:
"Except if you want to support very outdated distros (IIRC, < rhel5),
%defattr(-,root,root) is not necessary, anymore and should not be used
in specs anymore."
Reported-by: Ralf Corsepius <rc040203(a)freenet.de>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
---
ndctl.spec.in | 3 ---
1 file changed, 3 deletions(-)
diff --git a/ndctl.spec.in b/ndctl.spec.in
index e24b31cc54f0..6f6e99bd743b 100644
--- a/ndctl.spec.in
+++ b/ndctl.spec.in
@@ -65,19 +65,16 @@ make check
%postun -n LNAME -p /sbin/ldconfig
%files
-%defattr(-,root,root)
%license licenses/GPLv2 licenses/BSD-MIT licenses/CC0
%{_bindir}/ndctl
%{_mandir}/man1/*
%files -n LNAME
-%defattr(-,root,root)
%doc README.md
%license COPYING licenses/BSD-MIT licenses/CC0
%{_libdir}/libndctl.so.*
%files -n DNAME
-%defattr(-,root,root)
%license COPYING
%{_includedir}/ndctl/
%{_libdir}/libndctl.so
5 years, 8 months
[ndctl PATCH] ndctl: Grab kernel version from utsname()
by Johannes Thumshirn
Grab the kernel version used for tests dynamically via utsname() instead of
hardcoding the version of the build host.
Otherwise tests will be skipped if the build host had a too old kernel
version.
flodin:~ # ./ndctl test
__ndctl_test_attempt: skip test_libndctl:1950 requires: 4.2.0 current: 4.1.0
test-libndctl: SKIP
__ndctl_test_attempt: skip test_dpa_alloc:300 requires: 4.2.0 current: 4.1.0
test-dpa-alloc: SKIP
__ndctl_test_attempt: skip test_parent_uuid:230 requires: 4.3.0 current: 4.1.0
test-parent-uuid: SKIP
attempted: 3 skipped: 3
Signed-off-by: Johannes Thumshirn <jthumshirn(a)suse.de>
---
test/core.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
--- a/test/core.c
+++ b/test/core.c
@@ -1,4 +1,5 @@
#include <linux/version.h>
+#include <sys/utsname.h>
#include <stdlib.h>
#include <stdio.h>
#include <test.h>
@@ -11,6 +12,18 @@ struct ndctl_test {
int skip;
};
+static unsigned int get_system_kver(void)
+{
+ struct utsname utsname;
+ int a, b, c;
+
+ uname(&utsname);
+
+ sscanf(utsname.version, "%d.%d.%d", &a, &b, &c);
+
+ return KERNEL_VERSION(a,b,c);
+}
+
struct ndctl_test *ndctl_test_new(unsigned int kver)
{
struct ndctl_test *test = calloc(1, sizeof(*test));
@@ -19,7 +32,7 @@ struct ndctl_test *ndctl_test_new(unsign
return NULL;
if (!kver)
- test->kver = LINUX_VERSION_CODE;
+ test->kver = get_system_kver();
else
test->kver = kver;
5 years, 8 months
[ndctl PATCH 0/3] ndctl: clear error support for v52
by Dan Williams
Add libndctl support for the new "clear error" command based on section
9.20.7.6 "Function Index 4 - Clear Uncorrectable Error" from the ACPI
6.1 specification. This uncovered some minor address-range-scrub
command fixups.
---
Dan Williams (3):
ndctl: fix ndctl_bus_cmd_new_ars_status() input validation
ndctl: disable nfit_test regions after test
ndctl: add 'clear error' command support
configure.ac | 19 +++++++
lib/libndctl-ars.c | 127 ++++++++++++++++++++++++++++++++++++++++++------
lib/libndctl-private.h | 5 ++
lib/libndctl.c | 3 +
lib/libndctl.sym | 3 +
lib/ndctl/libndctl.h | 41 +++++++++++++++
ndctl.h | 13 +++++
test/libndctl.c | 68 +++++++++++++++++++++++++-
8 files changed, 259 insertions(+), 20 deletions(-)
5 years, 8 months
[PATCH 0/3] nfit, libnvdimm, pmem: clear poison support
by Dan Williams
ACPI 6.1 introduces the ability to send "clear error" commands to the
ACPI0012:00 device representing the root of an "nvdimm bus".
Similar to relocating a bad block on a disk, this support clears
media errors in response to a write.
---
Dan Williams (3):
nfit, libnvdimm: clear poison command support
libnvdimm, pmem: fix kmap_atomic() leak in error path
libnvdimm, pmem: clear poison on write
arch/x86/include/asm/pmem.h | 5 +++
drivers/acpi/nfit.c | 12 ++++++-
drivers/nvdimm/bus.c | 65 ++++++++++++++++++++++++++++++++++++++
drivers/nvdimm/nd.h | 2 +
drivers/nvdimm/pmem.c | 40 ++++++++++++++++++++---
include/linux/pmem.h | 19 +++++++++++
include/uapi/linux/ndctl.h | 13 ++++++++
tools/testing/nvdimm/test/nfit.c | 29 +++++++++++++++++
8 files changed, 179 insertions(+), 6 deletions(-)
5 years, 8 months
[PATCH v5 00/14] Support for transparent PUD pages for DAX files
by Matthew Wilcox
We have customer demand to use 1GB pages to map DAX files. Unlike the 2MB
page support, the Linux MM does not currently support PUD pages, so I have
attempted to add support for the necessary pieces for DAX huge PUD pages.
Filesystems still need work to allocate 1GB pages. With ext4, I can
only get 16MB of contiguous space, although it is aligned. With XFS,
I can get 80MB less than 1GB, and it's not aligned. The XFS problem
may be due to the small amount of RAM in my test machine.
This patch set is against v4.5-rc7-mmots-2016-03-08-15-59. I'd like
to thank Dave Chinner & Kirill Shutemov for their reviews of v1.
The conversion of pmd_fault & pud_fault to huge_fault is thanks to Dave's
poking, and Kirill spotted a couple of problems in the MM code.
I've done some light testing using a program to mmap a block device
with DAX enabled, calling mincore() and examining /proc/smaps and
/proc/pagemap.
v5: Fix compilation bug with GCC 4.5 and earlier by initialising vm_fault.pmd
and vm_fault.pud later
- Fix report from Sergey Senozhatsky about compilation on x86-64 with
CONFIG_TRANSPARENT_HUGEPAGE=n (also reported by Sudip Mukherjee)
- Fix report from Stephen Rothwell about touch_pud() / follow_devmap_pud()
not compiling on pSeries by moving these functions under
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
- Fix wrong order of arguments to VM_BUG_ON_VMA (reported by Andrew Morton)
- Fix VM_BUG_ON_* not checking its arguments in non-debug case
- Fix duplicate definition of native_pud_clear() with X86_PAE
- Fix linking with X86_PAE by making pud_trans_huge() and pud_devmap()
return 0
- Fix several whitespace issues in x86 patches
- Add some DAX cleanups on top of the 1GB changes
v4: Updated to current mmotm
- Converted pud_trans_huge_lock to the same calling conventions as
pmd_trans_huge_lock.
- Fill in vm_fault ->gfp_flags and ->pgoff, at Jan Kara's suggestion
- Replace use of page table lock with pud_lock in __pud_alloc (cosmetic)
- Fix compilation problems with various config settings
- Convert dax_pmd_fault and dax_pud_fault to take a vm_fault instead of
individual pieces
- Add copy_huge_pud() and follow_devmap_pud() so fork() should now work
- Fix typo of PMD for PUD
v3: Rebased against current mmtom
v2: Reduced churn in filesystems by switching to ->huge_fault interface
Addressed concerns from Kirill
Matthew Wilcox (14):
mmdebug: Always evaluate the arguments to VM_BUG_ON_*
mm: Convert an open-coded VM_BUG_ON_VMA
mm,fs,dax: Change ->pmd_fault to ->huge_fault
mm: Add support for PUD-sized transparent hugepages
mincore: Add support for PUDs
procfs: Add support for PUDs to smaps, clear_refs and pagemap
x86: Unify native_*_get_and_clear !SMP case
x86: Fix whitespace issues
x86: Add support for PUD-sized transparent hugepages
dax: Support for transparent PUD pages
ext4: Support for PUD-sized transparent huge pages
dax: Use vmf->gfp_mask
dax: Remove unnecessary rechecking of i_size
dax: Use vmf->pgoff in fault handlers
Documentation/filesystems/dax.txt | 12 +-
arch/Kconfig | 3 +
arch/x86/Kconfig | 1 +
arch/x86/include/asm/paravirt.h | 11 +
arch/x86/include/asm/paravirt_types.h | 2 +
arch/x86/include/asm/pgtable-2level.h | 21 +-
arch/x86/include/asm/pgtable-3level.h | 27 ++-
arch/x86/include/asm/pgtable.h | 162 ++++++++++++++-
arch/x86/include/asm/pgtable_64.h | 23 +--
arch/x86/kernel/paravirt.c | 1 +
arch/x86/mm/pgtable.c | 31 +++
fs/block_dev.c | 10 +-
fs/dax.c | 370 ++++++++++++++++++++--------------
fs/ext2/file.c | 25 +--
fs/ext4/file.c | 58 ++----
fs/proc/task_mmu.c | 109 ++++++++++
fs/xfs/xfs_file.c | 25 +--
fs/xfs/xfs_trace.h | 2 +-
include/asm-generic/pgtable.h | 73 ++++++-
include/asm-generic/tlb.h | 14 ++
include/linux/dax.h | 32 +--
include/linux/huge_mm.h | 84 +++++++-
include/linux/mm.h | 48 ++++-
include/linux/mmdebug.h | 21 +-
include/linux/mmu_notifier.h | 14 ++
include/linux/pfn_t.h | 8 +
mm/gup.c | 7 +
mm/huge_memory.c | 246 ++++++++++++++++++++++
mm/memory.c | 131 ++++++++++--
mm/mincore.c | 13 ++
mm/pagewalk.c | 19 +-
mm/pgtable-generic.c | 13 ++
32 files changed, 1284 insertions(+), 332 deletions(-)
--
2.7.0
5 years, 8 months
[ndctl PATCH] ndctl: add '--disable-docs' option to configure
by Dan Williams
For environments that want to build without the documentation add an
option to omit the Documentation/ sub-directory.
Reported-by: Arjan van de Ven <arjan(a)linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
---
Makefile.am | 2 ++
configure.ac | 9 +++++++++
2 files changed, 11 insertions(+)
diff --git a/Makefile.am b/Makefile.am
index ce97a15c7c0d..84582771e97d 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1,5 +1,7 @@
EXTRA_DIST =
+if ENABLE_DOCS
SUBDIRS = . Documentation
+endif
CLEANFILES =
ACLOCAL_AMFLAGS = -I m4 ${ACLOCAL_FLAGS}
AM_MAKEFLAGS = --no-print-directory
diff --git a/configure.ac b/configure.ac
index 9506e8e7dd25..96a02d9f9972 100644
--- a/configure.ac
+++ b/configure.ac
@@ -58,6 +58,15 @@ AS_IF([test "x$enable_logging" = "xyes"], [
AC_DEFINE(ENABLE_LOGGING, [1], [System logging.])
])
+AC_ARG_ENABLE([docs],
+ AS_HELP_STRING([--disable-docs],
+ [disable documentation build @<:@default=enabled@:>@]),
+ [], enable_docs=yes)
+AS_IF([test "x$enable_docs" = "xyes"], [
+ AC_DEFINE(ENABLE_DOCS, [1], [Documentation / man pages.])
+])
+AM_CONDITIONAL([ENABLE_DOCS], [test "x$enable_docs" = "xyes"])
+
AC_ARG_ENABLE([debug],
AS_HELP_STRING([--enable-debug], [enable debug messages @<:@default=disabled@:>@]),
[], [enable_debug=no])
5 years, 8 months
[PATCH v3 0/4] Support persistent memory as reserved type in e820/EFI
by Toshi Kani
ACPI 6 defines persistent memory (PMEM) ranges in multiple
firmware interfaces, e820, EFI, and ACPI NFIT table. This EFI
change, however, leads to hit a bug in the grub bootloader, which
treats EFI_PERSISTENT_MEMORY type as regular memory and corrupts
stored user data [1].
Therefore, BIOS may set generic reserved type in e820 and EFI
to cover PMEM ranges. The kernel can initialize PMEM ranges
from ACPI NFIT table alone.
This scheme cause a problem in the iomem table, though. On x86,
for instance, e820_reserve_resources() initializes top-level entries
(iomem_resource.child) from the e820 table at early boot-time.
This creates "reserved" entry for a PMEM range, which does not allow
region_intersects() to check with PMEM type.
This patch-set adds remove_resource(), exports insert/remove_resource(),
and changes the NFIT driver to insert a PMEM entry to the iomem table.
[1] https://lists.gnu.org/archive/html/grub-devel/2015-11/msg00209.html
- Patch 1 fixes __request_region() to handle inheritance of attribute
properly. This patch is independent from this series.
- Patch 2 adds remove_resource() interface.
- Patch 3 exports insert_resource() and remove_resource().
- Patch 4 changes the ACPI nfit driver to call insert_resource() to
insert a PMEM range from NFIT.
---
v3:
- Drop devm_insert/remove_resource(), and export insert/remove_resource().
(Linus Torvalds)
v2:
- Change the NFIT driver to call insert_resource() to insert a PMEM entry
when necessary. (Dan Williams)
- The NFIT driver still needs to allow unloading. (Dan Williams)
---
This patch-set is based on the tip tree, which has the following patchset.
https://lkml.org/lkml/2016/1/26/886
---
Toshi Kani (4):
1/4 resource: Change __request_region to inherit from immediate parent
2/4 resource: Add remove_resource interface
3/4 resource: Export insert_resource and remove_resource
4/4 ACPI: Change NFIT driver to insert new resource
---
drivers/acpi/nfit.c | 48 ++++++++++++++++++++++++++++++++++++++++
include/linux/ioport.h | 1 +
kernel/resource.c | 60 +++++++++++++++++++++++++++++++++++++++++++-------
3 files changed, 101 insertions(+), 8 deletions(-)
5 years, 8 months
[PATCH v3 1/4] resource: Change __request_region to inherit from immediate parent
by Toshi Kani
__request_region() sets 'flags' of a new resource from @parent
as it inherits the parent's attribute. When a target resource
has a conflict, this function inserts the new resource entry
under the conflicted entry by updating @parent. In this case,
the new resource entry needs to inherit attribute from the updated
parent. This conflict is a typical case since __request_region()
is used to allocate a new resource from a specific resource range.
For instance, request_mem_region() calls __request_region() with
@parent set to &iomem_resource, which is the root entry of the
whole iomem range. When this request results in inserting a new
entry "DEV-A" under "BUS-1", "DEV-A" needs to inherit from the
immediate parent "BUS-1" as it holds specific attribute for the
range.
root (&iomem_resource)
:
+ "BUS-1"
+ "DEV-A"
Change __request_region() to set 'flags' and 'desc' of a new entry
from the immediate parent.
Signed-off-by: Toshi Kani <toshi.kani(a)hpe.com>
Cc: Ingo Molnar <mingo(a)kernel.org>
Cc: Borislav Petkov <bp(a)suse.de>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Dan Williams <dan.j.williams(a)intel.com>
---
kernel/resource.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/kernel/resource.c b/kernel/resource.c
index 4d46605..5a56e8f 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -1085,15 +1085,16 @@ struct resource * __request_region(struct resource *parent,
res->name = name;
res->start = start;
res->end = start + n - 1;
- res->flags = resource_type(parent) | resource_ext_type(parent);
- res->flags |= IORESOURCE_BUSY | flags;
- res->desc = IORES_DESC_NONE;
write_lock(&resource_lock);
for (;;) {
struct resource *conflict;
+ res->flags = resource_type(parent) | resource_ext_type(parent);
+ res->flags |= IORESOURCE_BUSY | flags;
+ res->desc = parent->desc;
+
conflict = __request_resource(parent, res);
if (!conflict)
break;
5 years, 8 months
Re: [PATCH] pmem: don't allocate unused major device number
by Dan Williams
On Tue, Mar 8, 2016 at 2:21 PM, NeilBrown <neilb(a)suse.com> wrote:
>
> When alloc_disk(0) or alloc_disk-node(0, XX) is used, the ->major
> number is completely ignored: all devices are allocated with a
> major of BLOCK_EXT_MAJOR.
>
> So there is no point allocating pmem_major.
>
> Signed-off-by: NeilBrown <neilb(a)suse.com>
> ---
> drivers/nvdimm/pmem.c | 19 +------------------
> 1 file changed, 1 insertion(+), 18 deletions(-)
>
> Hi Dan et al,
> I was recently educating myself about the behavior of alloc_disk(0).
> As I understand it, the ->major is ignored and all device numbers for all
> partitions (including '0') are allocated on demand with major number of
> BLOCK_EXT_MAJOR.
>
> So I was a little surprised to find that pmem.c allocated a major
> number which is never used - historical anomaly I suspect.
> I was a bit more surprised at the comment in:
>
> Commit: 9f53f9fa4ad1 ("libnvdimm, pmem: add libnvdimm support to the pmem driver")
>
> "The minor numbers are also more predictable by passing 0 to alloc_disk()."
>
> How can they possibly be more predictable given that they are allocated
> on-demand? Maybe discovery order is very predictable???
>
> In any case, I propose this patch but cannot test it (beyond compiling)
> as I don't have relevant hardware. And maybe some user-space code greps
> /proc/devices for "pmem" to determine if "pmem" is compiled in (though
> I sincerely hope not).
> So I cannot be certain that this patch won't break anything, but am
> hoping that if you like it you might test it.
>
> If it does prove acceptable, then similar changes would be appropriate
> for btt.c and blk.c. And drivers/memstick/core/ms_block.c and
> drivers/nvme/host/core.c. (gotta stamp out this cargo cult)
This is passing my tests. Are you going to send these follow-ups as well?
5 years, 8 months
Re: [PATCH] pmem: don't allocate unused major device number
by Dan Williams
On Tue, Mar 8, 2016 at 2:21 PM, NeilBrown <neilb(a)suse.com> wrote:
>
> When alloc_disk(0) or alloc_disk-node(0, XX) is used, the ->major
> number is completely ignored: all devices are allocated with a
> major of BLOCK_EXT_MAJOR.
>
> So there is no point allocating pmem_major.
>
> Signed-off-by: NeilBrown <neilb(a)suse.com>
> ---
> drivers/nvdimm/pmem.c | 19 +------------------
> 1 file changed, 1 insertion(+), 18 deletions(-)
>
> Hi Dan et al,
> I was recently educating myself about the behavior of alloc_disk(0).
> As I understand it, the ->major is ignored and all device numbers for all
> partitions (including '0') are allocated on demand with major number of
> BLOCK_EXT_MAJOR.
>
> So I was a little surprised to find that pmem.c allocated a major
> number which is never used - historical anomaly I suspect.
> I was a bit more surprised at the comment in:
>
> Commit: 9f53f9fa4ad1 ("libnvdimm, pmem: add libnvdimm support to the pmem driver")
>
> "The minor numbers are also more predictable by passing 0 to alloc_disk()."
>
> How can they possibly be more predictable given that they are allocated
> on-demand? Maybe discovery order is very predictable???
Ross, I remember you looked into this when Boaz pointed out something similar.
> In any case, I propose this patch but cannot test it (beyond compiling)
> as I don't have relevant hardware. And maybe some user-space code greps
> /proc/devices for "pmem" to determine if "pmem" is compiled in (though
> I sincerely hope not).
> So I cannot be certain that this patch won't break anything, but am
> hoping that if you like it you might test it.
Will do.
Thanks Neil!
5 years, 8 months