On Tue, 2019-06-18 at 22:52 -0700, Dan Williams wrote: > The libnvdimm sub-system has suffered a series of hacks and broken > workarounds for the memory-hotplug implementation's awkward > section-aligned (128MB) granularity. For example the following > backtrace > is emitted when attempting arch_add_memory() with physical address > ranges that intersect 'System RAM' (RAM) with 'Persistent Memory' > (PMEM) > within a given section: > > # cat /proc/iomem | grep -A1 -B1 Persistent\ Memory > 100000000-1ffffffff : System RAM > 200000000-303ffffff : Persistent Memory (legacy) > 304000000-43fffffff : System RAM > 440000000-23ffffffff : Persistent Memory > 2400000000-43bfffffff : Persistent Memory > 2400000000-43bfffffff : namespace2.0 > > WARNING: CPU: 38 PID: 928 at arch/x86/mm/init_64.c:850 > add_pages+0x5c/0x60 > [..] > RIP: 0010:add_pages+0x5c/0x60 > [..] > Call Trace: > devm_memremap_pages+0x460/0x6e0 > pmem_attach_disk+0x29e/0x680 [nd_pmem] > ? nd_dax_probe+0xfc/0x120 [libnvdimm] > nvdimm_bus_probe+0x66/0x160 [libnvdimm] > > It was discovered that the problem goes beyond RAM vs PMEM collisions > as > some platform produce PMEM vs PMEM collisions within a given section. > The libnvdimm workaround for that case revealed that the libnvdimm > section-alignment-padding implementation has been broken for a long > while. A fix for that long-standing breakage introduces as many > problems > as it solves as it would require a backward-incompatible change to > the > namespace metadata interpretation. Instead of that dubious route [1], > address the root problem in the memory-hotplug implementation. > > Note that EEXIST is no longer treated as success as that is how > sparse_add_section() reports subsection collisions, it was also > obviated > by recent changes to perform the request_region() for 'System RAM' > before arch_add_memory() in the add_memory() sequence. > > [1]: https://lore.kernel.org/r/155000671719.348031.234736316014111923 > 7.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > Cc: Michal Hocko <mhocko@xxxxxxxx> > Cc: Vlastimil Babka <vbabka@xxxxxxx> > Cc: Logan Gunthorpe <logang@xxxxxxxxxxxx> > Cc: Oscar Salvador <osalvador@xxxxxxx> > Cc: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx> > Signed-off-by: Dan Williams <dan.j.williams@xxxxxxxxx> Reviewed-by: Oscar Salvador <osalvador@xxxxxxx> -- Oscar Salvador SUSE L3
