On Fri, Aug 16, 2019 at 8:34 PM Qian Cai <c...@lca.pw> wrote: > > > > > On Aug 16, 2019, at 5:48 PM, Dan Williams <dan.j.willi...@intel.com> wrote: > > > > On Fri, Aug 16, 2019 at 2:36 PM Qian Cai <c...@lca.pw> wrote: > >> > >> Every so often recently, booting Intel CPU server on linux-next triggers > >> this > >> warning. Trying to figure out if the commit 7cc7867fb061 > >> ("mm/devm_memremap_pages: enable sub-section remap") is the culprit here. > >> > >> # ./scripts/faddr2line vmlinux devm_memremap_pages+0x894/0xc70 > >> devm_memremap_pages+0x894/0xc70: > >> devm_memremap_pages at mm/memremap.c:307 > > > > Previously the forced section alignment in devm_memremap_pages() would > > cause the implementation to never violate the KASAN_SHADOW_SCALE_SIZE > > (12K on x86) constraint. > > > > Can you provide a dump of /proc/iomem? I'm curious what resource is > > triggering such a small alignment granularity. > > This is with memmap=4G!4G , > > # cat /proc/iomem [..] > 100000000-155dfffff : Persistent Memory (legacy) > 100000000-155dfffff : namespace0.0 > 155e00000-15982bfff : System RAM > 155e00000-156a00fa0 : Kernel code > 156a00fa1-15765d67f : Kernel data > 157837000-1597fffff : Kernel bss > 15982c000-1ffffffff : Persistent Memory (legacy) > 200000000-87fffffff : System RAM
Ok, looks like 4G is bad choice to land the pmem emulation on this system because it collides with where the kernel is deployed and gets broken into tiny pieces that violate kasan's. This is a known problem with memmap=. You need to pick an memory range that does not collide with anything else. See: https://nvdimm.wiki.kernel.org/how_to_choose_the_correct_memmap_kernel_parameter_for_pmem_on_your_system ...for more info.