[PATCH 0/2] Namespace creation fixups
by Keith Busch
This is a three-part fixup to the warning that occurs when the available
capacity is fragmented. When this occurs, the user may believe they can
create a larger namespace than is actually possible. This was resulting
in the following kernel warning:
nd_region region0: allocation underrun: 0x0 of 0x1400000000 bytes
WARNING: CPU: 32 PID: 1975 at drivers/nvdimm/namespace_devs.c:913 size_store+0x879/0x8d0 [libnvdimm]
The kernel side of this determines the maximum size by calculating the
largest contiguous extent that can be allocated. If the requested size
exceeds that, an error is returned early instead of reaching the
alarming kernel warning.
To make it possible for the user to know the maximum size it may
request, a new attribute is exported that shows the largest available
extent.
Finally, separate from this series, ndctl is updated to make use of this
new attribute when creating a namespace.
Keith Busch (2):
libnvdimm: Use largest contiguous area for namespace size
libnvdimm: Export max available extent
drivers/nvdimm/dimm_devs.c | 29 +++++++++++++++++++++++++++++
drivers/nvdimm/namespace_devs.c | 2 +-
drivers/nvdimm/nd-core.h | 3 +++
drivers/nvdimm/region_devs.c | 39 +++++++++++++++++++++++++++++++++++++++
4 files changed, 72 insertions(+), 1 deletion(-)
--
2.14.3
2 years, 7 months
[PATCH] nvdimm docs: remove reference to CONFIG_NFIT_TEST
by Ross Zwisler
This symbol doesn't currently exist. The instructions on how to compile &
load nfit_test are here:
https://github.com/pmem/ndctl
Signed-off-by: Ross Zwisler <ross.zwisler(a)linux.intel.com>
---
Documentation/nvdimm/nvdimm.txt | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/Documentation/nvdimm/nvdimm.txt b/Documentation/nvdimm/nvdimm.txt
index e894de69915a..985091a86866 100644
--- a/Documentation/nvdimm/nvdimm.txt
+++ b/Documentation/nvdimm/nvdimm.txt
@@ -248,9 +248,8 @@ by a region device with a dynamically assigned id (REGION0 - REGION5).
be contiguous in DPA-space.
This bus is provided by the kernel under the device
- /sys/devices/platform/nfit_test.0 when CONFIG_NFIT_TEST is enabled and
- the nfit_test.ko module is loaded. This not only test LIBNVDIMM but the
- acpi_nfit.ko driver as well.
+ /sys/devices/platform/nfit_test.0 when the nfit_test.ko module is loaded.
+ This not only test LIBNVDIMM but the acpi_nfit.ko driver as well.
LIBNVDIMM Kernel Device Model and LIBNDCTL Userspace API
--
2.14.4
2 years, 7 months
Good day!
by jasper＠unique-berlin.de
Good day!
We considered your resume to be very attractive and we thought the vacant position in our company could be interesting for you.
Our firm specializes in online services in the matter of business administration.
We cooperate with different countries and currently we have many clients in yours region.
Due to this fact, we need to increase the number of our destination representatives' regular staff.
Part-time and full-time employment are both currently important.
We offer a flat wage from $1500 up to $7000 per month.
If you are interested in our offer, please visit our web page.
Attention! Accept applications only on this and next week.
Respectively submitted
Personnel department
2 years, 8 months
[PATCH v2 0/4] Assigning NULL to gfn of dax_direct_access if useless
by Huaisheng Ye
From: Huaisheng Ye <yehs1(a)lenovo.com>
Changes since v1 [1]:
* Collect Jan's reviewed-by.
* According to Dan's suggestion, update the unit test infrastructure
tools/testing/nvdimm/pmem-dax.c for checking the validity of gfn.
[1]: https://lkml.org/lkml/2018/7/4/81
---
Some functions within fs/dax don't need to get gfn from direct_access.
Assigning NULL to gfn of dax_direct_access is more intuitive and simple
than offering a useless local variable.
So all direct_access need to check the validity of pointer pfn for NULL
assignment. If pfn equals to NULL, it doesn't need to calculate its value.
---
Huaisheng Ye (4):
nvdimm/pmem: check the validity of the pointer pfn
nvdimm/pmem-dax: check the validity of the pointer pfn
s390/block/dcssblk: check the validity of the pointer pfn
fs/dax: Assign NULL to gfn of dax_direct_access if useless
drivers/nvdimm/pmem.c | 3 ++-
drivers/s390/block/dcssblk.c | 3 ++-
fs/dax.c | 9 +++------
tools/testing/nvdimm/pmem-dax.c | 6 ++++--
4 files changed, 11 insertions(+), 10 deletions(-)
--
1.8.3.1
2 years, 8 months
Hello!
by gktye＠cassadyco.com
Good day!
We considered your resume to be very attractive and we thought the vacant position in our company could be interesting for you.
Our firm specializes in online services in the matter of business administration.
We cooperate with different countries and currently we have many clients in yours region.
Due to this fact, we need to increase the number of our destination representatives' regular staff.
Part-time and full-time employment are both currently important.
We offer a flat wage from $1500 up to $7000 per month.
If you are interested in our offer, please visit our web page.
Attention! Accept applications only on this and next week.
Respectively submitted
Personnel department
2 years, 8 months
[PATCH 1/3] nvdimm/pmem: check the validity of the pointer pfn
by Huaisheng Ye
From: Huaisheng Ye <yehs1(a)lenovo.com>
Some functions within fs/dax don't need to get gfn from direct_access.
Assigning NULL to gfn of dax_direct_access is more intuitive and simple
than offering a useless local variable.
So direct_access needs to check validity of the pointer pfn For NULL
assignment.
Signed-off-by: Huaisheng Ye <yehs1(a)lenovo.com>
---
drivers/nvdimm/pmem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index 9d71492..018f990 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -233,7 +233,8 @@ __weak long __pmem_direct_access(struct pmem_device *pmem, pgoff_t pgoff,
PFN_PHYS(nr_pages))))
return -EIO;
*kaddr = pmem->virt_addr + offset;
- *pfn = phys_to_pfn_t(pmem->phys_addr + offset, pmem->pfn_flags);
+ if (pfn)
+ *pfn = phys_to_pfn_t(pmem->phys_addr + offset, pmem->pfn_flags);
/*
* If badblocks are present, limit known good range to the
--
1.8.3.1
2 years, 8 months
[PATCH v4 00/12] mm: Teach memory_failure() about ZONE_DEVICE pages
by Dan Williams
Changes since v3 [1]:
* Introduce dax_lock_page(), using the radix exceptional entry lock, for
pinning down page->mapping while memory_failure() interrogates the
page. (Jan)
* Collect acks and reviews from Tony and Jan.
[1]: https://lists.01.org/pipermail/linux-nvdimm/2018-June/016153.html
---
As it stands, memory_failure() gets thoroughly confused by dev_pagemap
backed mappings. The recovery code has specific enabling for several
possible page states and needs new enabling to handle poison in dax
mappings.
In order to support reliable reverse mapping of user space addresses:
1/ Add new locking in the memory_failure() rmap path to prevent races
that would typically be handled by the page lock.
2/ Since dev_pagemap pages are hidden from the page allocator and the
"compound page" accounting machinery, add a mechanism to determine the
size of the mapping that encompasses a given poisoned pfn.
3/ Given pmem errors can be repaired, change the speculatively accessed
poison protection, mce_unmap_kpfn(), to be reversible and otherwise
allow ongoing access from the kernel.
A side effect of this enabling is that MADV_HWPOISON becomes usable for
dax mappings, however the primary motivation is to allow the system to
survive userspace consumption of hardware-poison via dax. Specifically
the current behavior is:
mce: Uncorrected hardware memory error in user-access at af34214200
{1}[Hardware Error]: It has been corrected by h/w and requires no further action
mce: [Hardware Error]: Machine check events logged
{1}[Hardware Error]: event severity: corrected
Memory failure: 0xaf34214: reserved kernel page still referenced by 1 users
[..]
Memory failure: 0xaf34214: recovery action for reserved kernel page: Failed
mce: Memory error not recovered
<reboot>
...and with these changes:
Injecting memory failure for pfn 0x20cb00 at process virtual address 0x7f763dd00000
Memory failure: 0x20cb00: Killing dax-pmd:5421 due to hardware memory corruption
Memory failure: 0x20cb00: recovery action for dax page: Recovered
---
Dan Williams (12):
device-dax: Convert to vmf_insert_mixed and vm_fault_t
device-dax: Cleanup vm_fault de-reference chains
device-dax: Enable page_mapping()
device-dax: Set page->index
filesystem-dax: Set page->index
mm, madvise_inject_error: Let memory_failure() optionally take a page reference
x86/mm/pat: Prepare {reserve,free}_memtype() for "decoy" addresses
x86/memory_failure: Introduce {set,clear}_mce_nospec()
mm, memory_failure: Pass page size to kill_proc()
filesystem-dax: Introduce dax_lock_page()
mm, memory_failure: Teach memory_failure() about dev_pagemap pages
libnvdimm, pmem: Restore page attributes when clearing errors
arch/x86/include/asm/set_memory.h | 42 +++++++++
arch/x86/kernel/cpu/mcheck/mce-internal.h | 15 ---
arch/x86/kernel/cpu/mcheck/mce.c | 38 +-------
arch/x86/mm/pat.c | 16 +++
drivers/dax/device.c | 97 ++++++++++++--------
drivers/nvdimm/pmem.c | 26 +++++
drivers/nvdimm/pmem.h | 13 +++
fs/dax.c | 92 ++++++++++++++++++-
include/linux/dax.h | 15 +++
include/linux/huge_mm.h | 5 +
include/linux/mm.h | 1
include/linux/set_memory.h | 14 +++
mm/huge_memory.c | 4 -
mm/madvise.c | 18 +++-
mm/memory-failure.c | 143 +++++++++++++++++++++++++++--
15 files changed, 434 insertions(+), 105 deletions(-)
2 years, 8 months
Hello!
by software＠itpgroup.co.uk
Good day!
We considered your resume to be very attractive and we thought the vacant position in our company could be interesting for you.
Our firm specializes in online services in the matter of business administration.
We cooperate with different countries and currently we have many clients in yours region.
Due to this fact, we need to increase the number of our destination representatives' regular staff.
Part-time and full-time employment are both currently important.
We offer a flat wage from $1500 up to $7000 per month.
If you are interested in our offer, please visit our web page.
Attention! Accept applications only on this and next week.
Respectively submitted
Personnel department
2 years, 8 months
