11 Nov, 2015
1 commit
-
Pull libnvdimm updates from Dan Williams:
"Outside of the new ACPI-NFIT hot-add support this pull request is more
notable for what it does not contain, than what it does. There were a
handful of development topics this cycle, dax get_user_pages, dax
fsync, and raw block dax, that need more more iteration and will wait
for 4.5.The patches to make devm and the pmem driver NUMA aware have been in
-next for several weeks. The hot-add support has not, but is
contained to the NFIT driver and is passing unit tests. The coredump
support is straightforward and was looked over by Jeff. All of it has
received a 0day build success notification across 107 configs.Summary:
- Add support for the ACPI 6.0 NFIT hot add mechanism to process
updates of the NFIT at runtime.- Teach the coredump implementation how to filter out DAX mappings.
- Introduce NUMA hints for allocations made by the pmem driver, and
as a side effect all devm allocations now hint their NUMA node by
default"* tag 'libnvdimm-for-4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
coredump: add DAX filtering for FDPIC ELF coredumps
coredump: add DAX filtering for ELF coredumps
acpi: nfit: Add support for hot-add
nfit: in acpi_nfit_init, break on a 0-length table
pmem, memremap: convert to numa aware allocations
devm_memremap_pages: use numa_mem_id
devm: make allocations numa aware by default
devm_memremap: convert to return ERR_PTR
devm_memunmap: use devres_release()
pmem: kill memremap_pmem()
x86, mm: quiet arch_add_memory()
27 Oct, 2015
1 commit
-
Currently memremap checks if the range is "System RAM" and returns the
kernel linear address. This is broken for highmem platforms where a
range may be "System RAM", but is not part of the kernel linear mapping.
Fallback to ioremap_cache() in these cases, to let the arch code attempt
to handle it.Note that ARM ioremap will WARN when attempting to remap ram, and in
that case the caller needs to be fixed. For this reason, existing
ioremap_cache() usages for ARM are already trained to avoid attempts to
remap ram.The impact of this bug is low for now since the pmem driver is the only
user of memremap(), but this is important to fix before more conversions
to memremap arrive in 4.4.Cc: Rafael J. Wysocki
Reported-by: Ard Biesheuvel
Acked-by: Ard Biesheuvel
Signed-off-by: Dan Williams
10 Oct, 2015
4 commits
-
Given that pmem ranges come with numa-locality hints, arrange for the
resulting driver objects to be obtained from node-local memory.Reviewed-by: Tejun Heo
Reviewed-by: Christoph Hellwig
Signed-off-by: Dan Williams -
Hint to closest numa node for the placement of newly allocated pages.
As that is where the device's other allocations will originate by
default when it does not specify a NUMA node.Cc: Ross Zwisler
Reviewed-by: Tejun Heo
Reviewed-by: Christoph Hellwig
Signed-off-by: Dan Williams -
Make devm_memremap consistent with the error return scheme of
devm_memremap_pages to remove special casing in the pmem driver.Cc: Christoph Hellwig
Cc: Ross Zwisler
Reviewed-by: Christoph Hellwig
Signed-off-by: Dan Williams -
Remove open coded call to memunmap.
Cc: Christoph Hellwig
Cc: Ross Zwisler
Reviewed-by: Christoph Hellwig
Signed-off-by: Dan Williams
28 Aug, 2015
1 commit
-
This behaves like devm_memremap except that it ensures we have page
structures available that can back the region.Signed-off-by: Christoph Hellwig
[djbw: catch attempts to remap RAM, drop flags]
Signed-off-by: Dan Williams
15 Aug, 2015
2 commits
-
Signed-off-by: Christoph Hellwig
Signed-off-by: Dan Williams -
Existing users of ioremap_cache() are mapping memory that is known in
advance to not have i/o side effects. These users are forced to cast
away the __iomem annotation, or otherwise neglect to fix the sparse
errors thrown when dereferencing pointers to this memory. Provide
memremap() as a non __iomem annotated ioremap_*() in the case when
ioremap is otherwise a pointer to cacheable memory. Empirically,
ioremap_() call sites are seeking memory-like semantics
(e.g. speculative reads, and prefetching permitted).memremap() is a break from the ioremap implementation pattern of adding
a new memremap_() for each mapping type and having silent
compatibility fall backs. Instead, the implementation defines flags
that are passed to the central memremap() and if a mapping type is not
supported by an arch memremap returns NULL.We introduce a memremap prototype as a trivial wrapper of
ioremap_cache() and ioremap_wt(). Later, once all ioremap_cache() and
ioremap_wt() usage has been removed from drivers we teach archs to
implement arch_memremap() with the ability to strictly enforce the
mapping type.Cc: Arnd Bergmann
Reviewed-by: Christoph Hellwig
Signed-off-by: Dan Williams