* devm_memremap_pages() triggers a kasan_add_zero_shadow() warning
@ 2019-08-16 21:35 ` Qian Cai
0 siblings, 0 replies; 21+ messages in thread
From: Qian Cai @ 2019-08-16 21:35 UTC (permalink / raw)
To: Dan Williams
Cc: linux-mm, Andrey Ryabinin, linux-kernel, kasan-dev, linux-nvdimm
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
[ 32.074412][ T294] WARNING: CPU: 31 PID: 294 at mm/kasan/init.c:496
kasan_add_zero_shadow.cold.2+0xc/0x39
[ 32.077448][ T294] Modules linked in:
[ 32.078614][ T294] CPU: 31 PID: 294 Comm: kworker/u97:1 Not tainted 5.3.0-
rc4-next-20190816+ #7
[ 32.081299][ T294] Hardware name: HP ProLiant XL420 Gen9/ProLiant XL420
Gen9, BIOS U19 12/27/2015
[ 32.084430][ T294] Workqueue: events_unbound async_run_entry_fn
[ 32.086347][ T294] RIP: 0010:kasan_add_zero_shadow.cold.2+0xc/0x39
[ 32.088303][ T294] Code: ff 48 c7 c7 b0 06 74 86 e8 0e e2 db ff 0f 0b e9 64
f7 ff ff 48 8b 45 98 48 89 45 b8 eb be 48 c7 c7 b0 06 74 86 e8 f1 e1 db ff <0f>
0b b8 ea ff ff ff e9 ad fe ff ff 48 c7 c7 b0 06 74 86 e8 d9 e1
[ 32.094183][ T294] RSP: 0000:ffff8884428cf738 EFLAGS: 00010282
[ 32.096030][ T294] RAX: 0000000000000024 RBX: ffff88833c1b8100 RCX:
ffffffff85730ba8
[ 32.098391][ T294] RDX: 0000000000000000 RSI: dffffc0000000000 RDI:
ffffffff86964740
[ 32.100802][ T294] RBP: ffff8884428cf750 R08: fffffbfff0d2c8e9 R09:
fffffbfff0d2c8e9
[ 32.103229][ T294] R10: fffffbfff0d2c8e8 R11: ffffffff86964743 R12:
1ffff11088519ef3
[ 32.105581][ T294] R13: ffff88833dbc8010 R14: 000000017a02c000 R15:
ffff88833c1b8128
[ 32.107956][ T294] FS: 0000000000000000(0000) GS:ffff88844db80000(0000)
knlGS:0000000000000000
[ 32.110585][ T294] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 32.112606][ T294] CR2: 0000000000000000 CR3: 0000000163012001 CR4:
00000000001606a0
[ 32.112610][ T294] Call Trace:
[ 32.112622][ T294] devm_memremap_pages+0x894/0xc70
[ 32.112635][ T294] ? devm_memremap_pages_release+0x510/0x510
[ 32.119291][ T294] ? do_raw_read_unlock+0x2c/0x60
[ 32.122470][ T332] namespace0.0 initialised, 400896 pages in 50ms
[ 32.143086][ T294] ? _raw_read_unlock+0x27/0x40
[ 32.143094][ T294] pmem_attach_disk+0x490/0x880
[ 32.143106][ T294] ? pmem_pagemap_kill+0x30/0x30
[ 32.186834][ T1] debug: unmapping init [mem 0xffffffff9d602000-
0xffffffff9d7fffff]
[ 32.195383][ T294] ? kfree+0x106/0x400
[ 32.195394][ T294] ? kfree_const+0x17/0x30
[ 32.314107][ T294] ? kobject_put+0xfb/0x250
[ 32.334569][ T294] ? put_device+0x13/0x20
[ 32.354169][ T294] nd_pmem_probe+0x83/0xa0
[ 32.374162][ T294] nvdimm_bus_probe+0xaa/0x1f0
[ 32.395901][ T294] really_probe+0x1a2/0x630
[ 32.416352][ T294] driver_probe_device+0xcd/0x1f0
[ 32.438901][ T294] __device_attach_driver+0xed/0x150
[ 32.463074][ T294] ? driver_allows_async_probing+0x90/0x90
[ 32.489538][ T294] bus_for_each_drv+0xfa/0x160
[ 32.511038][ T294] ? bus_rescan_devices+0x20/0x20
[ 32.731179][ T294] ? do_raw_spin_unlock+0xa8/0x140
[ 32.754475][ T294] __device_attach+0x16d/0x220
[ 32.775648][ T294] ? device_bind_driver+0x80/0x80
[ 32.798379][ T294] ? __kasan_check_write+0x14/0x20
[ 32.821550][ T294] ? wait_for_completion_io+0x20/0x20
[ 32.846143][ T294] device_initial_probe+0x13/0x20
[ 32.868959][ T294] bus_probe_device+0x10f/0x130
[ 32.891093][ T294] device_add+0xadb/0xd00
[ 32.910946][ T294] ? root_device_unregister+0x40/0x40
[ 32.935477][ T294] ? nd_synchronize+0x20/0x20
[ 32.956715][ T294] nd_async_device_register+0x12/0x40
[ 32.981106][ T294] async_run_entry_fn+0x7f/0x2d0
[ 33.003537][ T294] process_one_work+0x53b/0xa70
[ 33.026673][ T294] ? pwq_dec_nr_in_flight+0x170/0x170
[ 33.051060][ T294] worker_thread+0x63/0x5b0
[ 33.071431][ T294] kthread+0x1df/0x200
[ 33.089767][ T294] ? process_one_work+0xa70/0xa70
[ 33.112635][ T294] ? kthread_park+0xc0/0xc0
[ 33.132698][ T294] ret_from_fork+0x35/0x40
[ 33.155214][ T294] ---[ end trace 6917fee95b72ffee ]---
[ 33.182365][ T1] debug: unmapping init [mem 0xffffffff86e7b000-
0xffffffff87031fff]
[ 33.184491][ T332] pmem0: detected capacity change from 0 to 1642070016
[ 33.251029][ T294] nd_pmem: probe of namespace1.0 failed with error -22
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply [flat|nested] 21+ messages in thread
* devm_memremap_pages() triggers a kasan_add_zero_shadow() warning
@ 2019-08-16 21:35 ` Qian Cai
0 siblings, 0 replies; 21+ messages in thread
From: Qian Cai @ 2019-08-16 21:35 UTC (permalink / raw)
To: Dan Williams
Cc: linux-mm, linux-nvdimm, linux-kernel, Andrey Ryabinin, kasan-dev
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
[ 32.074412][ T294] WARNING: CPU: 31 PID: 294 at mm/kasan/init.c:496
kasan_add_zero_shadow.cold.2+0xc/0x39
[ 32.077448][ T294] Modules linked in:
[ 32.078614][ T294] CPU: 31 PID: 294 Comm: kworker/u97:1 Not tainted 5.3.0-
rc4-next-20190816+ #7
[ 32.081299][ T294] Hardware name: HP ProLiant XL420 Gen9/ProLiant XL420
Gen9, BIOS U19 12/27/2015
[ 32.084430][ T294] Workqueue: events_unbound async_run_entry_fn
[ 32.086347][ T294] RIP: 0010:kasan_add_zero_shadow.cold.2+0xc/0x39
[ 32.088303][ T294] Code: ff 48 c7 c7 b0 06 74 86 e8 0e e2 db ff 0f 0b e9 64
f7 ff ff 48 8b 45 98 48 89 45 b8 eb be 48 c7 c7 b0 06 74 86 e8 f1 e1 db ff <0f>
0b b8 ea ff ff ff e9 ad fe ff ff 48 c7 c7 b0 06 74 86 e8 d9 e1
[ 32.094183][ T294] RSP: 0000:ffff8884428cf738 EFLAGS: 00010282
[ 32.096030][ T294] RAX: 0000000000000024 RBX: ffff88833c1b8100 RCX:
ffffffff85730ba8
[ 32.098391][ T294] RDX: 0000000000000000 RSI: dffffc0000000000 RDI:
ffffffff86964740
[ 32.100802][ T294] RBP: ffff8884428cf750 R08: fffffbfff0d2c8e9 R09:
fffffbfff0d2c8e9
[ 32.103229][ T294] R10: fffffbfff0d2c8e8 R11: ffffffff86964743 R12:
1ffff11088519ef3
[ 32.105581][ T294] R13: ffff88833dbc8010 R14: 000000017a02c000 R15:
ffff88833c1b8128
[ 32.107956][ T294] FS: 0000000000000000(0000) GS:ffff88844db80000(0000)
knlGS:0000000000000000
[ 32.110585][ T294] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 32.112606][ T294] CR2: 0000000000000000 CR3: 0000000163012001 CR4:
00000000001606a0
[ 32.112610][ T294] Call Trace:
[ 32.112622][ T294] devm_memremap_pages+0x894/0xc70
[ 32.112635][ T294] ? devm_memremap_pages_release+0x510/0x510
[ 32.119291][ T294] ? do_raw_read_unlock+0x2c/0x60
[ 32.122470][ T332] namespace0.0 initialised, 400896 pages in 50ms
[ 32.143086][ T294] ? _raw_read_unlock+0x27/0x40
[ 32.143094][ T294] pmem_attach_disk+0x490/0x880
[ 32.143106][ T294] ? pmem_pagemap_kill+0x30/0x30
[ 32.186834][ T1] debug: unmapping init [mem 0xffffffff9d602000-
0xffffffff9d7fffff]
[ 32.195383][ T294] ? kfree+0x106/0x400
[ 32.195394][ T294] ? kfree_const+0x17/0x30
[ 32.314107][ T294] ? kobject_put+0xfb/0x250
[ 32.334569][ T294] ? put_device+0x13/0x20
[ 32.354169][ T294] nd_pmem_probe+0x83/0xa0
[ 32.374162][ T294] nvdimm_bus_probe+0xaa/0x1f0
[ 32.395901][ T294] really_probe+0x1a2/0x630
[ 32.416352][ T294] driver_probe_device+0xcd/0x1f0
[ 32.438901][ T294] __device_attach_driver+0xed/0x150
[ 32.463074][ T294] ? driver_allows_async_probing+0x90/0x90
[ 32.489538][ T294] bus_for_each_drv+0xfa/0x160
[ 32.511038][ T294] ? bus_rescan_devices+0x20/0x20
[ 32.731179][ T294] ? do_raw_spin_unlock+0xa8/0x140
[ 32.754475][ T294] __device_attach+0x16d/0x220
[ 32.775648][ T294] ? device_bind_driver+0x80/0x80
[ 32.798379][ T294] ? __kasan_check_write+0x14/0x20
[ 32.821550][ T294] ? wait_for_completion_io+0x20/0x20
[ 32.846143][ T294] device_initial_probe+0x13/0x20
[ 32.868959][ T294] bus_probe_device+0x10f/0x130
[ 32.891093][ T294] device_add+0xadb/0xd00
[ 32.910946][ T294] ? root_device_unregister+0x40/0x40
[ 32.935477][ T294] ? nd_synchronize+0x20/0x20
[ 32.956715][ T294] nd_async_device_register+0x12/0x40
[ 32.981106][ T294] async_run_entry_fn+0x7f/0x2d0
[ 33.003537][ T294] process_one_work+0x53b/0xa70
[ 33.026673][ T294] ? pwq_dec_nr_in_flight+0x170/0x170
[ 33.051060][ T294] worker_thread+0x63/0x5b0
[ 33.071431][ T294] kthread+0x1df/0x200
[ 33.089767][ T294] ? process_one_work+0xa70/0xa70
[ 33.112635][ T294] ? kthread_park+0xc0/0xc0
[ 33.132698][ T294] ret_from_fork+0x35/0x40
[ 33.155214][ T294] ---[ end trace 6917fee95b72ffee ]---
[ 33.182365][ T1] debug: unmapping init [mem 0xffffffff86e7b000-
0xffffffff87031fff]
[ 33.184491][ T332] pmem0: detected capacity change from 0 to 1642070016
[ 33.251029][ T294] nd_pmem: probe of namespace1.0 failed with error -22
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: devm_memremap_pages() triggers a kasan_add_zero_shadow() warning
2019-08-16 21:35 ` Qian Cai
(?)
@ 2019-08-16 21:48 ` Dan Williams
-1 siblings, 0 replies; 21+ messages in thread
From: Dan Williams @ 2019-08-16 21:48 UTC (permalink / raw)
To: Qian Cai
Cc: Linux MM, Andrey Ryabinin, Linux Kernel Mailing List, kasan-dev,
linux-nvdimm
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?
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: devm_memremap_pages() triggers a kasan_add_zero_shadow() warning
@ 2019-08-16 21:48 ` Dan Williams
0 siblings, 0 replies; 21+ 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] 21+ messages in thread
* Re: devm_memremap_pages() triggers a kasan_add_zero_shadow() warning
@ 2019-08-16 21:48 ` Dan Williams
0 siblings, 0 replies; 21+ 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] 21+ messages in thread
* Re: devm_memremap_pages() triggers a kasan_add_zero_shadow() warning
2019-08-16 21:48 ` Dan Williams
(?)
(?)
@ 2019-08-17 3:34 ` Qian Cai
2019-08-17 3:57 ` Dan Williams
-1 siblings, 1 reply; 21+ 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] 21+ 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 3:57 ` Dan Williams
0 siblings, 0 replies; 21+ messages in thread
From: Dan Williams @ 2019-08-17 3:57 UTC (permalink / raw)
To: Qian Cai
Cc: Linux MM, Andrey Ryabinin, Linux Kernel Mailing List, kasan-dev,
linux-nvdimm
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.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: devm_memremap_pages() triggers a kasan_add_zero_shadow() warning
@ 2019-08-17 3:57 ` Dan Williams
0 siblings, 0 replies; 21+ 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] 21+ messages in thread
* Re: devm_memremap_pages() triggers a kasan_add_zero_shadow() warning
@ 2019-08-17 3:57 ` Dan Williams
0 siblings, 0 replies; 21+ 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] 21+ 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
-1 siblings, 0 replies; 21+ messages in thread
From: Qian Cai @ 2019-08-17 11:12 UTC (permalink / raw)
To: Dan Williams
Cc: Linux MM, Andrey Ryabinin, Linux Kernel Mailing List, kasan-dev,
linux-nvdimm
> 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.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: devm_memremap_pages() triggers a kasan_add_zero_shadow() warning
@ 2019-08-17 11:12 ` Qian Cai
0 siblings, 0 replies; 21+ 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] 21+ 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
-1 siblings, 0 replies; 21+ messages in thread
From: Dan Williams @ 2019-08-17 16:59 UTC (permalink / raw)
To: Qian Cai
Cc: Linux MM, Andrey Ryabinin, Linux Kernel Mailing List, kasan-dev,
linux-nvdimm
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.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: devm_memremap_pages() triggers a kasan_add_zero_shadow() warning
@ 2019-08-17 16:59 ` Dan Williams
0 siblings, 0 replies; 21+ 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] 21+ messages in thread
* Re: devm_memremap_pages() triggers a kasan_add_zero_shadow() warning
@ 2019-08-17 16:59 ` Dan Williams
0 siblings, 0 replies; 21+ 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] 21+ 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
-1 siblings, 1 reply; 21+ 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] 21+ 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-21 21:12 ` Qian Cai
0 siblings, 0 replies; 21+ messages in thread
From: Qian Cai @ 2019-08-21 21:12 UTC (permalink / raw)
To: Dan Williams
Cc: Baoquan He, linux-nvdimm, Linux Kernel Mailing List, kasan-dev,
Linux MM, Andrey Ryabinin, 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.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: devm_memremap_pages() triggers a kasan_add_zero_shadow() warning
@ 2019-08-21 21:12 ` Qian Cai
0 siblings, 0 replies; 21+ 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] 21+ messages in thread
* Re: devm_memremap_pages() triggers a kasan_add_zero_shadow() warning
@ 2019-08-21 21:12 ` Qian Cai
0 siblings, 0 replies; 21+ 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] 21+ 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
-1 siblings, 0 replies; 21+ messages in thread
From: Baoquan He @ 2019-08-22 1:31 UTC (permalink / raw)
To: Qian Cai
Cc: linux-nvdimm, Linux Kernel Mailing List, kasan-dev, Linux MM,
Andrey Ryabinin, 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
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: devm_memremap_pages() triggers a kasan_add_zero_shadow() warning
@ 2019-08-22 1:31 ` Baoquan He
0 siblings, 0 replies; 21+ 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] 21+ 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
-1 siblings, 0 replies; 21+ 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] 21+ messages in thread
end of thread, other threads:[~2019-08-22 1:52 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-16 21:35 devm_memremap_pages() triggers a kasan_add_zero_shadow() warning Qian Cai
2019-08-16 21:35 ` Qian Cai
2019-08-16 21:48 ` Dan Williams
2019-08-16 21:48 ` Dan Williams
2019-08-16 21:48 ` Dan Williams
2019-08-17 3:34 ` Qian Cai
2019-08-17 3:57 ` Dan Williams
2019-08-17 3:57 ` Dan Williams
2019-08-17 3:57 ` Dan Williams
2019-08-17 11:12 ` Qian Cai
2019-08-17 11:12 ` Qian Cai
2019-08-17 16:59 ` Dan Williams
2019-08-17 16:59 ` Dan Williams
2019-08-17 16:59 ` Dan Williams
2019-08-18 3:25 ` Qian Cai
2019-08-21 21:12 ` Qian Cai
2019-08-21 21:12 ` Qian Cai
2019-08-21 21:12 ` Qian Cai
2019-08-22 1:31 ` Baoquan He
2019-08-22 1:31 ` Baoquan He
2019-08-22 1:52 ` Qian Cai
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.