* Re: devm_memremap_pages() triggers a kasan_add_zero_shadow() warning [not found] <1565991345.8572.28.camel@lca.pw> @ 2019-08-16 21:48 ` Dan Williams 2019-08-17 3:34 ` Qian Cai 0 siblings, 1 reply; 9+ messages in thread From: Dan Williams @ 2019-08-16 21:48 UTC (permalink / raw) To: Qian Cai Cc: Linux MM, linux-nvdimm, Linux Kernel Mailing List, Andrey Ryabinin, kasan-dev On Fri, Aug 16, 2019 at 2:36 PM Qian Cai <cai@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. Is it truly only linux-next or does latest mainline have this issue as well? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: devm_memremap_pages() triggers a kasan_add_zero_shadow() warning 2019-08-16 21:48 ` devm_memremap_pages() triggers a kasan_add_zero_shadow() warning Dan Williams @ 2019-08-17 3:34 ` Qian Cai 2019-08-17 3:57 ` Dan Williams 0 siblings, 1 reply; 9+ messages in thread From: Qian Cai @ 2019-08-17 3:34 UTC (permalink / raw) To: Dan Williams Cc: Linux MM, linux-nvdimm, Linux Kernel Mailing List, Andrey Ryabinin, kasan-dev > On Aug 16, 2019, at 5:48 PM, Dan Williams <dan.j.williams@intel.com> wrote: > > On Fri, Aug 16, 2019 at 2:36 PM Qian Cai <cai@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 00000000-00000fff : Reserved 00001000-00093fff : System RAM 00094000-0009ffff : Reserved 000a0000-000bffff : PCI Bus 0000:00 000c0000-000c7fff : Video ROM 000c8000-000cbfff : Adapter ROM 000cc000-000ccfff : Adapter ROM 000e0000-000fffff : Reserved 000f0000-000fffff : System ROM 00100000-5a7a0fff : System RAM 5a7a1000-5b5e0fff : Reserved 5b5e1000-790fefff : System RAM 69000000-78ffffff : Crash kernel 790ff000-791fefff : Reserved 791ff000-7b5fefff : ACPI Non-volatile Storage 7b5ff000-7b7fefff : ACPI Tables 7b7ff000-7b7fffff : System RAM 7b800000-8fffffff : Reserved 80000000-8fffffff : PCI MMCONFIG 0000 [bus 00-ff] 90000000-c7ffbfff : PCI Bus 0000:00 90000000-92afffff : PCI Bus 0000:01 90000000-9000ffff : 0000:01:00.2 91000000-91ffffff : 0000:01:00.1 92000000-927fffff : 0000:01:00.1 92800000-928fffff : 0000:01:00.2 92900000-929fffff : 0000:01:00.2 92a00000-92a7ffff : 0000:01:00.2 92a80000-92a87fff : 0000:01:00.2 92a88000-92a8bfff : 0000:01:00.1 92a8c000-92a8c0ff : 0000:01:00.2 92a8d000-92a8d1ff : 0000:01:00.0 92b00000-92dfffff : PCI Bus 0000:02 92b00000-92bfffff : 0000:02:00.1 92b00000-92bfffff : igb 92c00000-92cfffff : 0000:02:00.0 92c00000-92cfffff : igb 92d00000-92d03fff : 0000:02:00.1 92d00000-92d03fff : igb 92d04000-92d07fff : 0000:02:00.0 92d04000-92d07fff : igb 92d80000-92dfffff : 0000:02:00.0 92e00000-92ffffff : PCI Bus 0000:03 92e00000-92efffff : 0000:03:00.0 92e00000-92efffff : hpsa 92f00000-92f003ff : 0000:03:00.0 92f00000-92f003ff : hpsa 92f80000-92ffffff : 0000:03:00.0 93000000-930003ff : 0000:00:1d.0 93001000-930013ff : 0000:00:1a.0 93003000-93003fff : 0000:00:05.4 c7ffc000-c7ffcfff : dmar1 c8000000-fbffbfff : PCI Bus 0000:80 c8000000-c8000fff : 0000:80:05.4 fbffc000-fbffcfff : dmar0 fec00000-fecfffff : PNP0003:00 fec00000-fec003ff : IOAPIC 0 fec01000-fec013ff : IOAPIC 1 fec40000-fec403ff : IOAPIC 2 fed00000-fed003ff : HPET 0 fed00000-fed003ff : PNP0103:00 fed12000-fed1200f : pnp 00:01 fed12010-fed1201f : pnp 00:01 fed1b000-fed1bfff : pnp 00:01 fed1c000-fed3ffff : pnp 00:01 fed45000-fed8bfff : pnp 00:01 fee00000-feefffff : pnp 00:01 fee00000-fee00fff : Local APIC ff800000-ffffffff : Reserved 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 858000000-877ffffff : Crash kernel 38000000000-39fffffffff : PCI Bus 0000:00 39fffe00000-39fffefffff : PCI Bus 0000:02 39ffff00000-39ffff0ffff : 0000:00:14.0 39ffff10000-39ffff13fff : 0000:00:04.7 39ffff14000-39ffff17fff : 0000:00:04.6 39ffff18000-39ffff1bfff : 0000:00:04.5 39ffff1c000-39ffff1ffff : 0000:00:04.4 39ffff20000-39ffff23fff : 0000:00:04.3 39ffff24000-39ffff27fff : 0000:00:04.2 39ffff28000-39ffff2bfff : 0000:00:04.1 39ffff2c000-39ffff2ffff : 0000:00:04.0 39ffff31000-39ffff310ff : 0000:00:1f.3 3a000000000-3bfffffffff : PCI Bus 0000:80 3bffff00000-3bffff03fff : 0000:80:04.7 3bffff04000-3bffff07fff : 0000:80:04.6 3bffff08000-3bffff0bfff : 0000:80:04.5 3bffff0c000-3bffff0ffff : 0000:80:04.4 3bffff10000-3bffff13fff : 0000:80:04.3 3bffff14000-3bffff17fff : 0000:80:04.2 3bffff18000-3bffff1bfff : 0000:80:04.1 3bffff1c000-3bffff1ffff : 0000:80:04.0 > > Is it truly only linux-next or does latest mainline have this issue as well? No idea. I have not had a chance to test it on the mainline yet. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: devm_memremap_pages() triggers a kasan_add_zero_shadow() warning 2019-08-17 3:34 ` Qian Cai @ 2019-08-17 3:57 ` Dan Williams 2019-08-17 11:12 ` Qian Cai 0 siblings, 1 reply; 9+ messages in thread From: Dan Williams @ 2019-08-17 3:57 UTC (permalink / raw) To: Qian Cai Cc: Linux MM, linux-nvdimm, Linux Kernel Mailing List, Andrey Ryabinin, kasan-dev On Fri, Aug 16, 2019 at 8:34 PM Qian Cai <cai@lca.pw> wrote: > > > > > On Aug 16, 2019, at 5:48 PM, Dan Williams <dan.j.williams@intel.com> wrote: > > > > On Fri, Aug 16, 2019 at 2:36 PM Qian Cai <cai@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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: devm_memremap_pages() triggers a kasan_add_zero_shadow() warning 2019-08-17 3:57 ` Dan Williams @ 2019-08-17 11:12 ` Qian Cai 2019-08-17 16:59 ` Dan Williams 0 siblings, 1 reply; 9+ messages in thread From: Qian Cai @ 2019-08-17 11:12 UTC (permalink / raw) To: Dan Williams Cc: Linux MM, linux-nvdimm, Linux Kernel Mailing List, Andrey Ryabinin, kasan-dev > On Aug 16, 2019, at 11:57 PM, Dan Williams <dan.j.williams@intel.com> wrote: > > On Fri, Aug 16, 2019 at 8:34 PM Qian Cai <cai@lca.pw> wrote: >> >> >> >>> On Aug 16, 2019, at 5:48 PM, Dan Williams <dan.j.williams@intel.com> wrote: >>> >>> On Fri, Aug 16, 2019 at 2:36 PM Qian Cai <cai@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. Well, it seems I did exactly follow the information in that link, [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x0000000000093fff] usable [ 0.000000] BIOS-e820: [mem 0x0000000000094000-0x000000000009ffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000005a7a0fff] usable [ 0.000000] BIOS-e820: [mem 0x000000005a7a1000-0x000000005b5e0fff] reserved [ 0.000000] BIOS-e820: [mem 0x000000005b5e1000-0x00000000790fefff] usable [ 0.000000] BIOS-e820: [mem 0x00000000790ff000-0x00000000791fefff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000791ff000-0x000000007b5fefff] ACPI NVS [ 0.000000] BIOS-e820: [mem 0x000000007b5ff000-0x000000007b7fefff] ACPI data [ 0.000000] BIOS-e820: [mem 0x000000007b7ff000-0x000000007b7fffff] usable [ 0.000000] BIOS-e820: [mem 0x000000007b800000-0x000000008fffffff] reserved [ 0.000000] BIOS-e820: [mem 0x00000000ff800000-0x00000000ffffffff] reserved [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000087fffffff] usable Where 4G is good. Then, [ 0.000000] user-defined physical RAM map: [ 0.000000] user: [mem 0x0000000000000000-0x0000000000093fff] usable [ 0.000000] user: [mem 0x0000000000094000-0x000000000009ffff] reserved [ 0.000000] user: [mem 0x00000000000e0000-0x00000000000fffff] reserved [ 0.000000] user: [mem 0x0000000000100000-0x000000005a7a0fff] usable [ 0.000000] user: [mem 0x000000005a7a1000-0x000000005b5e0fff] reserved [ 0.000000] user: [mem 0x000000005b5e1000-0x00000000790fefff] usable [ 0.000000] user: [mem 0x00000000790ff000-0x00000000791fefff] reserved [ 0.000000] user: [mem 0x00000000791ff000-0x000000007b5fefff] ACPI NVS [ 0.000000] user: [mem 0x000000007b5ff000-0x000000007b7fefff] ACPI data [ 0.000000] user: [mem 0x000000007b7ff000-0x000000007b7fffff] usable [ 0.000000] user: [mem 0x000000007b800000-0x000000008fffffff] reserved [ 0.000000] user: [mem 0x00000000ff800000-0x00000000ffffffff] reserved [ 0.000000] user: [mem 0x0000000100000000-0x00000001ffffffff] persistent (type 12) [ 0.000000] user: [mem 0x0000000200000000-0x000000087fffffff] usable The doc did mention that “There seems to be an issue with CONFIG_KSAN at the moment however.” without more detail though. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: devm_memremap_pages() triggers a kasan_add_zero_shadow() warning 2019-08-17 11:12 ` Qian Cai @ 2019-08-17 16:59 ` Dan Williams 2019-08-18 3:25 ` Qian Cai 0 siblings, 1 reply; 9+ messages in thread From: Dan Williams @ 2019-08-17 16:59 UTC (permalink / raw) To: Qian Cai Cc: Linux MM, linux-nvdimm, Linux Kernel Mailing List, Andrey Ryabinin, kasan-dev On Sat, Aug 17, 2019 at 4:13 AM Qian Cai <cai@lca.pw> wrote: > > > > > On Aug 16, 2019, at 11:57 PM, Dan Williams <dan.j.williams@intel.com> wrote: > > > > On Fri, Aug 16, 2019 at 8:34 PM Qian Cai <cai@lca.pw> wrote: > >> > >> > >> > >>> On Aug 16, 2019, at 5:48 PM, Dan Williams <dan.j.williams@intel.com> wrote: > >>> > >>> On Fri, Aug 16, 2019 at 2:36 PM Qian Cai <cai@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. > > Well, it seems I did exactly follow the information in that link, > > [ 0.000000] BIOS-provided physical RAM map: > [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x0000000000093fff] usable > [ 0.000000] BIOS-e820: [mem 0x0000000000094000-0x000000000009ffff] reserved > [ 0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved > [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000005a7a0fff] usable > [ 0.000000] BIOS-e820: [mem 0x000000005a7a1000-0x000000005b5e0fff] reserved > [ 0.000000] BIOS-e820: [mem 0x000000005b5e1000-0x00000000790fefff] usable > [ 0.000000] BIOS-e820: [mem 0x00000000790ff000-0x00000000791fefff] reserved > [ 0.000000] BIOS-e820: [mem 0x00000000791ff000-0x000000007b5fefff] ACPI NVS > [ 0.000000] BIOS-e820: [mem 0x000000007b5ff000-0x000000007b7fefff] ACPI data > [ 0.000000] BIOS-e820: [mem 0x000000007b7ff000-0x000000007b7fffff] usable > [ 0.000000] BIOS-e820: [mem 0x000000007b800000-0x000000008fffffff] reserved > [ 0.000000] BIOS-e820: [mem 0x00000000ff800000-0x00000000ffffffff] reserved > [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000087fffffff] usable > > Where 4G is good. Then, > > [ 0.000000] user-defined physical RAM map: > [ 0.000000] user: [mem 0x0000000000000000-0x0000000000093fff] usable > [ 0.000000] user: [mem 0x0000000000094000-0x000000000009ffff] reserved > [ 0.000000] user: [mem 0x00000000000e0000-0x00000000000fffff] reserved > [ 0.000000] user: [mem 0x0000000000100000-0x000000005a7a0fff] usable > [ 0.000000] user: [mem 0x000000005a7a1000-0x000000005b5e0fff] reserved > [ 0.000000] user: [mem 0x000000005b5e1000-0x00000000790fefff] usable > [ 0.000000] user: [mem 0x00000000790ff000-0x00000000791fefff] reserved > [ 0.000000] user: [mem 0x00000000791ff000-0x000000007b5fefff] ACPI NVS > [ 0.000000] user: [mem 0x000000007b5ff000-0x000000007b7fefff] ACPI data > [ 0.000000] user: [mem 0x000000007b7ff000-0x000000007b7fffff] usable > [ 0.000000] user: [mem 0x000000007b800000-0x000000008fffffff] reserved > [ 0.000000] user: [mem 0x00000000ff800000-0x00000000ffffffff] reserved > [ 0.000000] user: [mem 0x0000000100000000-0x00000001ffffffff] persistent (type 12) > [ 0.000000] user: [mem 0x0000000200000000-0x000000087fffffff] usable > > The doc did mention that “There seems to be an issue with CONFIG_KSAN at the moment however.” > without more detail though. Does disabling CONFIG_RANDOMIZE_BASE help? Maybe that workaround has regressed. Effectively we need to find what is causing the kernel to sometimes be placed in the middle of a custom reserved memmap= range. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: devm_memremap_pages() triggers a kasan_add_zero_shadow() warning 2019-08-17 16:59 ` Dan Williams @ 2019-08-18 3:25 ` Qian Cai 2019-08-21 21:12 ` Qian Cai 0 siblings, 1 reply; 9+ messages in thread From: Qian Cai @ 2019-08-18 3:25 UTC (permalink / raw) To: Dan Williams Cc: Linux MM, linux-nvdimm, Linux Kernel Mailing List, Andrey Ryabinin, kasan-dev, Baoquan He, Dave Jiang, Thomas Gleixner > On Aug 17, 2019, at 12:59 PM, Dan Williams <dan.j.williams@intel.com> wrote: > > On Sat, Aug 17, 2019 at 4:13 AM Qian Cai <cai@lca.pw> wrote: >> >> >> >>> On Aug 16, 2019, at 11:57 PM, Dan Williams <dan.j.williams@intel.com> wrote: >>> >>> On Fri, Aug 16, 2019 at 8:34 PM Qian Cai <cai@lca.pw> wrote: >>>> >>>> >>>> >>>>> On Aug 16, 2019, at 5:48 PM, Dan Williams <dan.j.williams@intel.com> wrote: >>>>> >>>>> On Fri, Aug 16, 2019 at 2:36 PM Qian Cai <cai@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. >> >> Well, it seems I did exactly follow the information in that link, >> >> [ 0.000000] BIOS-provided physical RAM map: >> [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x0000000000093fff] usable >> [ 0.000000] BIOS-e820: [mem 0x0000000000094000-0x000000000009ffff] reserved >> [ 0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved >> [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000005a7a0fff] usable >> [ 0.000000] BIOS-e820: [mem 0x000000005a7a1000-0x000000005b5e0fff] reserved >> [ 0.000000] BIOS-e820: [mem 0x000000005b5e1000-0x00000000790fefff] usable >> [ 0.000000] BIOS-e820: [mem 0x00000000790ff000-0x00000000791fefff] reserved >> [ 0.000000] BIOS-e820: [mem 0x00000000791ff000-0x000000007b5fefff] ACPI NVS >> [ 0.000000] BIOS-e820: [mem 0x000000007b5ff000-0x000000007b7fefff] ACPI data >> [ 0.000000] BIOS-e820: [mem 0x000000007b7ff000-0x000000007b7fffff] usable >> [ 0.000000] BIOS-e820: [mem 0x000000007b800000-0x000000008fffffff] reserved >> [ 0.000000] BIOS-e820: [mem 0x00000000ff800000-0x00000000ffffffff] reserved >> [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000087fffffff] usable >> >> Where 4G is good. Then, >> >> [ 0.000000] user-defined physical RAM map: >> [ 0.000000] user: [mem 0x0000000000000000-0x0000000000093fff] usable >> [ 0.000000] user: [mem 0x0000000000094000-0x000000000009ffff] reserved >> [ 0.000000] user: [mem 0x00000000000e0000-0x00000000000fffff] reserved >> [ 0.000000] user: [mem 0x0000000000100000-0x000000005a7a0fff] usable >> [ 0.000000] user: [mem 0x000000005a7a1000-0x000000005b5e0fff] reserved >> [ 0.000000] user: [mem 0x000000005b5e1000-0x00000000790fefff] usable >> [ 0.000000] user: [mem 0x00000000790ff000-0x00000000791fefff] reserved >> [ 0.000000] user: [mem 0x00000000791ff000-0x000000007b5fefff] ACPI NVS >> [ 0.000000] user: [mem 0x000000007b5ff000-0x000000007b7fefff] ACPI data >> [ 0.000000] user: [mem 0x000000007b7ff000-0x000000007b7fffff] usable >> [ 0.000000] user: [mem 0x000000007b800000-0x000000008fffffff] reserved >> [ 0.000000] user: [mem 0x00000000ff800000-0x00000000ffffffff] reserved >> [ 0.000000] user: [mem 0x0000000100000000-0x00000001ffffffff] persistent (type 12) >> [ 0.000000] user: [mem 0x0000000200000000-0x000000087fffffff] usable >> >> The doc did mention that “There seems to be an issue with CONFIG_KSAN at the moment however.” >> without more detail though. > > Does disabling CONFIG_RANDOMIZE_BASE help? Maybe that workaround has > regressed. Effectively we need to find what is causing the kernel to > sometimes be placed in the middle of a custom reserved memmap= range. Yes, disabling KASLR works good so far. Assuming the workaround, i.e., f28442497b5c (“x86/boot: Fix KASLR and memmap= collision”) is correct. The only other commit that might regress it from my research so far is, d52e7d5a952c ("x86/KASLR: Parse all 'memmap=' boot option entries”) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: devm_memremap_pages() triggers a kasan_add_zero_shadow() warning 2019-08-18 3:25 ` Qian Cai @ 2019-08-21 21:12 ` Qian Cai 2019-08-22 1:31 ` Baoquan He 0 siblings, 1 reply; 9+ messages in thread From: Qian Cai @ 2019-08-21 21:12 UTC (permalink / raw) To: Dan Williams Cc: Linux MM, linux-nvdimm, Linux Kernel Mailing List, Andrey Ryabinin, kasan-dev, Baoquan He, Dave Jiang, Thomas Gleixner On Sat, 2019-08-17 at 23:25 -0400, Qian Cai wrote: > > On Aug 17, 2019, at 12:59 PM, Dan Williams <dan.j.williams@intel.com> wrote: > > > > On Sat, Aug 17, 2019 at 4:13 AM Qian Cai <cai@lca.pw> wrote: > > > > > > > > > > > > > On Aug 16, 2019, at 11:57 PM, Dan Williams <dan.j.williams@intel.com> > > > > wrote: > > > > > > > > On Fri, Aug 16, 2019 at 8:34 PM Qian Cai <cai@lca.pw> wrote: > > > > > > > > > > > > > > > > > > > > > On Aug 16, 2019, at 5:48 PM, Dan Williams <dan.j.williams@intel.com> > > > > > > wrote: > > > > > > > > > > > > On Fri, Aug 16, 2019 at 2:36 PM Qian Cai <cai@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. > > > > > > Well, it seems I did exactly follow the information in that link, > > > > > > [ 0.000000] BIOS-provided physical RAM map: > > > [ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x0000000000093fff] > > > usable > > > [ 0.000000] BIOS-e820: [mem 0x0000000000094000-0x000000000009ffff] > > > reserved > > > [ 0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] > > > reserved > > > [ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000005a7a0fff] > > > usable > > > [ 0.000000] BIOS-e820: [mem 0x000000005a7a1000-0x000000005b5e0fff] > > > reserved > > > [ 0.000000] BIOS-e820: [mem 0x000000005b5e1000-0x00000000790fefff] > > > usable > > > [ 0.000000] BIOS-e820: [mem 0x00000000790ff000-0x00000000791fefff] > > > reserved > > > [ 0.000000] BIOS-e820: [mem 0x00000000791ff000-0x000000007b5fefff] ACPI > > > NVS > > > [ 0.000000] BIOS-e820: [mem 0x000000007b5ff000-0x000000007b7fefff] ACPI > > > data > > > [ 0.000000] BIOS-e820: [mem 0x000000007b7ff000-0x000000007b7fffff] > > > usable > > > [ 0.000000] BIOS-e820: [mem 0x000000007b800000-0x000000008fffffff] > > > reserved > > > [ 0.000000] BIOS-e820: [mem 0x00000000ff800000-0x00000000ffffffff] > > > reserved > > > [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000087fffffff] > > > usable > > > > > > Where 4G is good. Then, > > > > > > [ 0.000000] user-defined physical RAM map: > > > [ 0.000000] user: [mem 0x0000000000000000-0x0000000000093fff] usable > > > [ 0.000000] user: [mem 0x0000000000094000-0x000000000009ffff] reserved > > > [ 0.000000] user: [mem 0x00000000000e0000-0x00000000000fffff] reserved > > > [ 0.000000] user: [mem 0x0000000000100000-0x000000005a7a0fff] usable > > > [ 0.000000] user: [mem 0x000000005a7a1000-0x000000005b5e0fff] reserved > > > [ 0.000000] user: [mem 0x000000005b5e1000-0x00000000790fefff] usable > > > [ 0.000000] user: [mem 0x00000000790ff000-0x00000000791fefff] reserved > > > [ 0.000000] user: [mem 0x00000000791ff000-0x000000007b5fefff] ACPI NVS > > > [ 0.000000] user: [mem 0x000000007b5ff000-0x000000007b7fefff] ACPI data > > > [ 0.000000] user: [mem 0x000000007b7ff000-0x000000007b7fffff] usable > > > [ 0.000000] user: [mem 0x000000007b800000-0x000000008fffffff] reserved > > > [ 0.000000] user: [mem 0x00000000ff800000-0x00000000ffffffff] reserved > > > [ 0.000000] user: [mem 0x0000000100000000-0x00000001ffffffff] > > > persistent (type 12) > > > [ 0.000000] user: [mem 0x0000000200000000-0x000000087fffffff] usable > > > > > > The doc did mention that “There seems to be an issue with CONFIG_KSAN at > > > the moment however.” > > > without more detail though. > > > > Does disabling CONFIG_RANDOMIZE_BASE help? Maybe that workaround has > > regressed. Effectively we need to find what is causing the kernel to > > sometimes be placed in the middle of a custom reserved memmap= range. > > Yes, disabling KASLR works good so far. Assuming the workaround, i.e., > f28442497b5c > (“x86/boot: Fix KASLR and memmap= collision”) is correct. > > The only other commit that might regress it from my research so far is, > > d52e7d5a952c ("x86/KASLR: Parse all 'memmap=' boot option entries”) > It turns out that the origin commit f28442497b5c (“x86/boot: Fix KASLR and memmap= collision”) has a bug that is unable to handle "memmap=" in CONFIG_CMDLINE instead of a parameter in bootloader because when it (as well as the commit d52e7d5a952c) calls get_cmd_line_ptr() in order to run mem_avoid_memmap(), "boot_params" has no knowledge of CONFIG_CMDLINE. Only later in setup_arch(), the kernel will deal with parameters over there. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: devm_memremap_pages() triggers a kasan_add_zero_shadow() warning 2019-08-21 21:12 ` Qian Cai @ 2019-08-22 1:31 ` Baoquan He 2019-08-22 1:52 ` Qian Cai 0 siblings, 1 reply; 9+ messages in thread From: Baoquan He @ 2019-08-22 1:31 UTC (permalink / raw) To: Qian Cai Cc: Dan Williams, Linux MM, linux-nvdimm, Linux Kernel Mailing List, Andrey Ryabinin, kasan-dev, Dave Jiang, Thomas Gleixner On 08/21/19 at 05:12pm, Qian Cai wrote: > > > Does disabling CONFIG_RANDOMIZE_BASE help? Maybe that workaround has > > > regressed. Effectively we need to find what is causing the kernel to > > > sometimes be placed in the middle of a custom reserved memmap= range. > > > > Yes, disabling KASLR works good so far. Assuming the workaround, i.e., > > f28442497b5c > > (“x86/boot: Fix KASLR and memmap= collision”) is correct. > > > > The only other commit that might regress it from my research so far is, > > > > d52e7d5a952c ("x86/KASLR: Parse all 'memmap=' boot option entries”) > > > > It turns out that the origin commit f28442497b5c (“x86/boot: Fix KASLR and > memmap= collision”) has a bug that is unable to handle "memmap=" in > CONFIG_CMDLINE instead of a parameter in bootloader because when it (as well as > the commit d52e7d5a952c) calls get_cmd_line_ptr() in order to run > mem_avoid_memmap(), "boot_params" has no knowledge of CONFIG_CMDLINE. Only later > in setup_arch(), the kernel will deal with parameters over there. Yes, we didn't consider CONFIG_CMDLINE during boot compressing stage. It should be a generic issue since other parameters from CONFIG_CMDLINE could be ignored too, not only KASLR handling. Would you like to cast a patch to fix it? Or I can fix it later, maybe next week. Thanks Baoquan ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: devm_memremap_pages() triggers a kasan_add_zero_shadow() warning 2019-08-22 1:31 ` Baoquan He @ 2019-08-22 1:52 ` Qian Cai 0 siblings, 0 replies; 9+ messages in thread From: Qian Cai @ 2019-08-22 1:52 UTC (permalink / raw) To: Baoquan He Cc: Dan Williams, Linux MM, linux-nvdimm, Linux Kernel Mailing List, Andrey Ryabinin, kasan-dev, Dave Jiang, Thomas Gleixner > On Aug 21, 2019, at 9:31 PM, Baoquan He <bhe@redhat.com> wrote: > > On 08/21/19 at 05:12pm, Qian Cai wrote: >>>> Does disabling CONFIG_RANDOMIZE_BASE help? Maybe that workaround has >>>> regressed. Effectively we need to find what is causing the kernel to >>>> sometimes be placed in the middle of a custom reserved memmap= range. >>> >>> Yes, disabling KASLR works good so far. Assuming the workaround, i.e., >>> f28442497b5c >>> (“x86/boot: Fix KASLR and memmap= collision”) is correct. >>> >>> The only other commit that might regress it from my research so far is, >>> >>> d52e7d5a952c ("x86/KASLR: Parse all 'memmap=' boot option entries”) >>> >> >> It turns out that the origin commit f28442497b5c (“x86/boot: Fix KASLR and >> memmap= collision”) has a bug that is unable to handle "memmap=" in >> CONFIG_CMDLINE instead of a parameter in bootloader because when it (as well as >> the commit d52e7d5a952c) calls get_cmd_line_ptr() in order to run >> mem_avoid_memmap(), "boot_params" has no knowledge of CONFIG_CMDLINE. Only later >> in setup_arch(), the kernel will deal with parameters over there. > > Yes, we didn't consider CONFIG_CMDLINE during boot compressing stage. It > should be a generic issue since other parameters from CONFIG_CMDLINE could > be ignored too, not only KASLR handling. Would you like to cast a patch > to fix it? Or I can fix it later, maybe next week. I think you have more experience than me in this area, so if you have time to fix it, that would be nice. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-08-22 1:52 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <1565991345.8572.28.camel@lca.pw>
2019-08-16 21:48 ` devm_memremap_pages() triggers a kasan_add_zero_shadow() warning Dan Williams
2019-08-17 3:34 ` Qian Cai
2019-08-17 3:57 ` Dan Williams
2019-08-17 11:12 ` Qian Cai
2019-08-17 16:59 ` Dan Williams
2019-08-18 3:25 ` Qian Cai
2019-08-21 21:12 ` Qian Cai
2019-08-22 1:31 ` Baoquan He
2019-08-22 1:52 ` Qian Cai
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).