* 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).