Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
Hi Baoquan, At 02/08/2018 09:23 AM, Baoquan He wrote: On 02/08/18 at 09:14am, Dou Liyang wrote: Hi Baoquan, At 02/07/2018 08:45 PM, Baoquan He wrote: On 02/07/18 at 08:34pm, Dou Liyang wrote: At 02/07/2018 08:27 PM, Baoquan He wrote: On 02/07/18 at 08:17pm, Dou Liyang wrote: Hi Baoquan, At 02/07/2018 08:08 PM, Baoquan He wrote: On 02/07/18 at 08:00pm, Dou Liyang wrote: Hi Kirill,Mike At 02/07/2018 06:45 PM, Mike Galbraith wrote: On Wed, 2018-02-07 at 13:41 +0300, Kirill A. Shutemov wrote: On Wed, Feb 07, 2018 at 05:25:05PM +0800, Dou Liyang wrote: Hi All, I met the makedumpfile failed in the upstream kernel which contained this patch. Did I missed something else? None I'm aware of. Is there a reason to suspect that the issue is related to the bug this patch fixed? I did a contrastive test by my colleagues Indoh's suggestion. OK, I may get the reason. kaslr is enabled, right? You can try to I add 'nokaslr' to disable the KASLR feature. ~~~added?? oops! yes, the kaslr had already disabled by this option when I tested. # cat /proc/cmdline BOOT_IMAGE=/vmlinuz-4.15.0+ root=UUID=10f10326-c923-4098-86aa-afed5c54ee0b ro crashkernel=512M rhgb console=tty0 console=ttyS0 nokaslr LANG=en_US.UTF-8 disable kaslr and try them again. Because phys_base and kaslr_offset are got from vmlinux, while these are generated at compiling time. Just a guess. Oh, I will recompile the kernel with KASLR disabled in .config. Then it's not what I guessed. Need debug makedumpfile since using vmlinux is another code path, few people use it usually. Understood, I will try to look into it. Thanks, dou Thanks, dou. Revert your two commits: commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 Author: Kirill A. ShutemovDate: Fri Sep 29 17:08:16 2017 +0300 commit 629a359bdb0e0652a8227b4ff3125431995fec6e Author: Kirill A. Shutemov Date: Tue Nov 7 11:33:37 2017 +0300 ...and keep others unchanged, the makedumpfile works well. Still works fine for me with .today. Box is only 16GB desktop box though. Btw, In the upstream kernel which contained this patch, I did two tests: 1) use the makedumpfile as core_collector in /etc/kdump.conf, then trigger the process of kdump by echo 1 >/proc/sysrq-trigger, the makedumpfile works well and I can get the vmcore file. ..It is OK 2) use cp as core_collector, do the same operation to get the vmcore file. then use makedumpfile to do like above: [douly@localhost code]$ ./makedumpfile -d 31 --message-level 31 -x vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ Oh, then please ignore my previous comment. Adding '-D' can give more debugging message. I added '-D', Just like before, no more debugging message: BTW, I use crash to analyze the vmcore file created by 'cp' command. ./crash ../makedumpfile/code/vmcore_4.15+_from_cp_command ../makedumpfile/code/vmlinux_4.15+ the crash works well, It's so interesting. Thanks, dou. The debugging message with '-D': And what's the debugging printing when trigger crash by sysrq? kdump: dump target is /dev/vda2 kdump: saving to /sysroot//var/crash/127.0.0.1-2018-02-07-07:31:56/ [2.751352] EXT4-fs (vda2): re-mounted. Opts: data=ordered kdump: saving vmcore-dmesg.txt kdump: saving vmcore-dmesg.txt complete kdump: saving vmcore sadump: does not have partition header sadump: read dump device as unknown format sadump: unknown format LOAD (0) phys_start : 100 phys_end : 2a86000 virt_start : 8100 virt_end : 82a86000 LOAD (1) phys_start : 1000 phys_end : 9fc00 virt_start : 88001000 virt_end : 8809fc00 LOAD (2) phys_start : 10 phys_end : 1300 virt_start : 8810 virt_end : 88001300 LOAD (3) phys_start : 3300 phys_end : 7ffd7000 virt_start : 88003300 virt_end : 88007ffd7000 Linux kdump page_size: 4096 max_mapnr: 7ffd7 Buffer size for the cyclic mode: 131061 num of NODEs : 1 Memory type : SPARSEMEM_EX mem_map (0) mem_map: ea00 pfn_start : 0 pfn_end: 8000 mem_map (1) mem_map: ea20 pfn_start : 8000 pfn_end: 1 mem_map (2) mem_map: ea40 pfn_start : 1 pfn_end: 18000 mem_map (3) mem_map: ea60 pfn_start : 18000 pfn_end: 2 mem_map (4) mem_map: ea80 pfn_start : 2 pfn_end: 28000 mem_map (5) mem_map: eaa0 pfn_start : 28000 pfn_end: 3 mem_map (6) mem_map: eac0 pfn_start : 3 pfn_end: 38000 mem_map (7) mem_map: eae0 pfn_start : 38000 pfn_end: 4 mem_map (8) mem_map: ea000100 pfn_start : 4 pfn_end:
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
Hi Baoquan, At 02/08/2018 09:23 AM, Baoquan He wrote: On 02/08/18 at 09:14am, Dou Liyang wrote: Hi Baoquan, At 02/07/2018 08:45 PM, Baoquan He wrote: On 02/07/18 at 08:34pm, Dou Liyang wrote: At 02/07/2018 08:27 PM, Baoquan He wrote: On 02/07/18 at 08:17pm, Dou Liyang wrote: Hi Baoquan, At 02/07/2018 08:08 PM, Baoquan He wrote: On 02/07/18 at 08:00pm, Dou Liyang wrote: Hi Kirill,Mike At 02/07/2018 06:45 PM, Mike Galbraith wrote: On Wed, 2018-02-07 at 13:41 +0300, Kirill A. Shutemov wrote: On Wed, Feb 07, 2018 at 05:25:05PM +0800, Dou Liyang wrote: Hi All, I met the makedumpfile failed in the upstream kernel which contained this patch. Did I missed something else? None I'm aware of. Is there a reason to suspect that the issue is related to the bug this patch fixed? I did a contrastive test by my colleagues Indoh's suggestion. OK, I may get the reason. kaslr is enabled, right? You can try to I add 'nokaslr' to disable the KASLR feature. ~~~added?? oops! yes, the kaslr had already disabled by this option when I tested. # cat /proc/cmdline BOOT_IMAGE=/vmlinuz-4.15.0+ root=UUID=10f10326-c923-4098-86aa-afed5c54ee0b ro crashkernel=512M rhgb console=tty0 console=ttyS0 nokaslr LANG=en_US.UTF-8 disable kaslr and try them again. Because phys_base and kaslr_offset are got from vmlinux, while these are generated at compiling time. Just a guess. Oh, I will recompile the kernel with KASLR disabled in .config. Then it's not what I guessed. Need debug makedumpfile since using vmlinux is another code path, few people use it usually. Understood, I will try to look into it. Thanks, dou Thanks, dou. Revert your two commits: commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 Author: Kirill A. Shutemov Date: Fri Sep 29 17:08:16 2017 +0300 commit 629a359bdb0e0652a8227b4ff3125431995fec6e Author: Kirill A. Shutemov Date: Tue Nov 7 11:33:37 2017 +0300 ...and keep others unchanged, the makedumpfile works well. Still works fine for me with .today. Box is only 16GB desktop box though. Btw, In the upstream kernel which contained this patch, I did two tests: 1) use the makedumpfile as core_collector in /etc/kdump.conf, then trigger the process of kdump by echo 1 >/proc/sysrq-trigger, the makedumpfile works well and I can get the vmcore file. ..It is OK 2) use cp as core_collector, do the same operation to get the vmcore file. then use makedumpfile to do like above: [douly@localhost code]$ ./makedumpfile -d 31 --message-level 31 -x vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ Oh, then please ignore my previous comment. Adding '-D' can give more debugging message. I added '-D', Just like before, no more debugging message: BTW, I use crash to analyze the vmcore file created by 'cp' command. ./crash ../makedumpfile/code/vmcore_4.15+_from_cp_command ../makedumpfile/code/vmlinux_4.15+ the crash works well, It's so interesting. Thanks, dou. The debugging message with '-D': And what's the debugging printing when trigger crash by sysrq? kdump: dump target is /dev/vda2 kdump: saving to /sysroot//var/crash/127.0.0.1-2018-02-07-07:31:56/ [2.751352] EXT4-fs (vda2): re-mounted. Opts: data=ordered kdump: saving vmcore-dmesg.txt kdump: saving vmcore-dmesg.txt complete kdump: saving vmcore sadump: does not have partition header sadump: read dump device as unknown format sadump: unknown format LOAD (0) phys_start : 100 phys_end : 2a86000 virt_start : 8100 virt_end : 82a86000 LOAD (1) phys_start : 1000 phys_end : 9fc00 virt_start : 88001000 virt_end : 8809fc00 LOAD (2) phys_start : 10 phys_end : 1300 virt_start : 8810 virt_end : 88001300 LOAD (3) phys_start : 3300 phys_end : 7ffd7000 virt_start : 88003300 virt_end : 88007ffd7000 Linux kdump page_size: 4096 max_mapnr: 7ffd7 Buffer size for the cyclic mode: 131061 num of NODEs : 1 Memory type : SPARSEMEM_EX mem_map (0) mem_map: ea00 pfn_start : 0 pfn_end: 8000 mem_map (1) mem_map: ea20 pfn_start : 8000 pfn_end: 1 mem_map (2) mem_map: ea40 pfn_start : 1 pfn_end: 18000 mem_map (3) mem_map: ea60 pfn_start : 18000 pfn_end: 2 mem_map (4) mem_map: ea80 pfn_start : 2 pfn_end: 28000 mem_map (5) mem_map: eaa0 pfn_start : 28000 pfn_end: 3 mem_map (6) mem_map: eac0 pfn_start : 3 pfn_end: 38000 mem_map (7) mem_map: eae0 pfn_start : 38000 pfn_end: 4 mem_map (8) mem_map: ea000100 pfn_start : 4 pfn_end: 48000 mem_map (9) mem_map: ea000120 pfn_start
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On 02/08/18 at 09:14am, Dou Liyang wrote: > Hi Baoquan, > > At 02/07/2018 08:45 PM, Baoquan He wrote: > > On 02/07/18 at 08:34pm, Dou Liyang wrote: > > > > > > > > > At 02/07/2018 08:27 PM, Baoquan He wrote: > > > > On 02/07/18 at 08:17pm, Dou Liyang wrote: > > > > > Hi Baoquan, > > > > > > > > > > At 02/07/2018 08:08 PM, Baoquan He wrote: > > > > > > On 02/07/18 at 08:00pm, Dou Liyang wrote: > > > > > > > Hi Kirill,Mike > > > > > > > > > > > > > > At 02/07/2018 06:45 PM, Mike Galbraith wrote: > > > > > > > > On Wed, 2018-02-07 at 13:41 +0300, Kirill A. Shutemov wrote: > > > > > > > > > On Wed, Feb 07, 2018 at 05:25:05PM +0800, Dou Liyang wrote: > > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > > > > > I met the makedumpfile failed in the upstream kernel which > > > > > > > > > > contained > > > > > > > > > > this patch. Did I missed something else? > > > > > > > > > > > > > > > > > > None I'm aware of. > > > > > > > > > > > > > > > > > > Is there a reason to suspect that the issue is related to the > > > > > > > > > bug this patch > > > > > > > > > fixed? > > > > > > > > > > > > > > > > > > > > > > I did a contrastive test by my colleagues Indoh's suggestion. > > > > OK, I may get the reason. kaslr is enabled, right? You can try to > > I add 'nokaslr' to disable the KASLR feature. ~~~added?? > > # cat /proc/cmdline > BOOT_IMAGE=/vmlinuz-4.15.0+ root=UUID=10f10326-c923-4098-86aa-afed5c54ee0b > ro crashkernel=512M rhgb console=tty0 console=ttyS0 nokaslr LANG=en_US.UTF-8 > > > disable kaslr and try them again. Because phys_base and kaslr_offset are > > got from vmlinux, while these are generated at compiling time. Just a > > guess. > > > > Oh, I will recompile the kernel with KASLR disabled in .config. Then it's not what I guessed. Need debug makedumpfile since using vmlinux is another code path, few people use it usually. > > > Thanks, > dou. > > > > > > > > > > > > > > Revert your two commits: > > > > > > > > > > > > > > commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 > > > > > > > Author: Kirill A. Shutemov> > > > > > > Date: Fri Sep 29 17:08:16 2017 +0300 > > > > > > > > > > > > > > commit 629a359bdb0e0652a8227b4ff3125431995fec6e > > > > > > > Author: Kirill A. Shutemov > > > > > > > Date: Tue Nov 7 11:33:37 2017 +0300 > > > > > > > > > > > > > > ...and keep others unchanged, the makedumpfile works well. > > > > > > > > > > > > > > > Still works fine for me with .today. Box is only 16GB desktop > > > > > > > > box though. > > > > > > > > > > > > > > > Btw, In the upstream kernel which contained this patch, I did two > > > > > > > tests: > > > > > > > > > > > > > > 1) use the makedumpfile as core_collector in /etc/kdump.conf, > > > > > > > then > > > > > > > trigger the process of kdump by echo 1 >/proc/sysrq-trigger, the > > > > > > > makedumpfile works well and I can get the vmcore file. > > > > > > > > > > > > > > ..It is OK > > > > > > > > > > > > > > 2) use cp as core_collector, do the same operation to get the > > > > > > > vmcore file. > > > > > > > then use makedumpfile to do like above: > > > > > > > > > > > > > >[douly@localhost code]$ ./makedumpfile -d 31 > > > > > > > --message-level 31 -x > > > > > > > vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ > > > > > > > > > > > > Oh, then please ignore my previous comment. Adding '-D' can give > > > > > > more > > > > > > debugging message. > > > > > > > > > > I added '-D', Just like before, no more debugging message: > > > > > > > > > > BTW, I use crash to analyze the vmcore file created by 'cp' command. > > > > > > > > > > ./crash ../makedumpfile/code/vmcore_4.15+_from_cp_command > > > > > ../makedumpfile/code/vmlinux_4.15+ > > > > > > > > > > the crash works well, It's so interesting. > > > > > > > > > > Thanks, > > > > > dou. > > > > > > > > > > The debugging message with '-D': > > > > > > > > And what's the debugging printing when trigger crash by sysrq? > > > > > > > > > > kdump: dump target is /dev/vda2 > > > kdump: saving to /sysroot//var/crash/127.0.0.1-2018-02-07-07:31:56/ > > > [2.751352] EXT4-fs (vda2): re-mounted. Opts: data=ordered > > > kdump: saving vmcore-dmesg.txt > > > kdump: saving vmcore-dmesg.txt complete > > > kdump: saving vmcore > > > sadump: does not have partition header > > > sadump: read dump device as unknown format > > > sadump: unknown format > > > LOAD (0) > > >phys_start : 100 > > >phys_end : 2a86000 > > >virt_start : 8100 > > >virt_end : 82a86000 > > > LOAD (1) > > >phys_start : 1000 > > >phys_end : 9fc00 > > >virt_start : 88001000 > > >virt_end : 8809fc00 > > > LOAD (2) > > >phys_start : 10 > > >phys_end : 1300 > > >virt_start : 8810 > > >virt_end : 88001300 > > > LOAD (3) > > >phys_start :
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On 02/08/18 at 09:14am, Dou Liyang wrote: > Hi Baoquan, > > At 02/07/2018 08:45 PM, Baoquan He wrote: > > On 02/07/18 at 08:34pm, Dou Liyang wrote: > > > > > > > > > At 02/07/2018 08:27 PM, Baoquan He wrote: > > > > On 02/07/18 at 08:17pm, Dou Liyang wrote: > > > > > Hi Baoquan, > > > > > > > > > > At 02/07/2018 08:08 PM, Baoquan He wrote: > > > > > > On 02/07/18 at 08:00pm, Dou Liyang wrote: > > > > > > > Hi Kirill,Mike > > > > > > > > > > > > > > At 02/07/2018 06:45 PM, Mike Galbraith wrote: > > > > > > > > On Wed, 2018-02-07 at 13:41 +0300, Kirill A. Shutemov wrote: > > > > > > > > > On Wed, Feb 07, 2018 at 05:25:05PM +0800, Dou Liyang wrote: > > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > > > > > I met the makedumpfile failed in the upstream kernel which > > > > > > > > > > contained > > > > > > > > > > this patch. Did I missed something else? > > > > > > > > > > > > > > > > > > None I'm aware of. > > > > > > > > > > > > > > > > > > Is there a reason to suspect that the issue is related to the > > > > > > > > > bug this patch > > > > > > > > > fixed? > > > > > > > > > > > > > > > > > > > > > > I did a contrastive test by my colleagues Indoh's suggestion. > > > > OK, I may get the reason. kaslr is enabled, right? You can try to > > I add 'nokaslr' to disable the KASLR feature. ~~~added?? > > # cat /proc/cmdline > BOOT_IMAGE=/vmlinuz-4.15.0+ root=UUID=10f10326-c923-4098-86aa-afed5c54ee0b > ro crashkernel=512M rhgb console=tty0 console=ttyS0 nokaslr LANG=en_US.UTF-8 > > > disable kaslr and try them again. Because phys_base and kaslr_offset are > > got from vmlinux, while these are generated at compiling time. Just a > > guess. > > > > Oh, I will recompile the kernel with KASLR disabled in .config. Then it's not what I guessed. Need debug makedumpfile since using vmlinux is another code path, few people use it usually. > > > Thanks, > dou. > > > > > > > > > > > > > > Revert your two commits: > > > > > > > > > > > > > > commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 > > > > > > > Author: Kirill A. Shutemov > > > > > > > Date: Fri Sep 29 17:08:16 2017 +0300 > > > > > > > > > > > > > > commit 629a359bdb0e0652a8227b4ff3125431995fec6e > > > > > > > Author: Kirill A. Shutemov > > > > > > > Date: Tue Nov 7 11:33:37 2017 +0300 > > > > > > > > > > > > > > ...and keep others unchanged, the makedumpfile works well. > > > > > > > > > > > > > > > Still works fine for me with .today. Box is only 16GB desktop > > > > > > > > box though. > > > > > > > > > > > > > > > Btw, In the upstream kernel which contained this patch, I did two > > > > > > > tests: > > > > > > > > > > > > > > 1) use the makedumpfile as core_collector in /etc/kdump.conf, > > > > > > > then > > > > > > > trigger the process of kdump by echo 1 >/proc/sysrq-trigger, the > > > > > > > makedumpfile works well and I can get the vmcore file. > > > > > > > > > > > > > > ..It is OK > > > > > > > > > > > > > > 2) use cp as core_collector, do the same operation to get the > > > > > > > vmcore file. > > > > > > > then use makedumpfile to do like above: > > > > > > > > > > > > > >[douly@localhost code]$ ./makedumpfile -d 31 > > > > > > > --message-level 31 -x > > > > > > > vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ > > > > > > > > > > > > Oh, then please ignore my previous comment. Adding '-D' can give > > > > > > more > > > > > > debugging message. > > > > > > > > > > I added '-D', Just like before, no more debugging message: > > > > > > > > > > BTW, I use crash to analyze the vmcore file created by 'cp' command. > > > > > > > > > > ./crash ../makedumpfile/code/vmcore_4.15+_from_cp_command > > > > > ../makedumpfile/code/vmlinux_4.15+ > > > > > > > > > > the crash works well, It's so interesting. > > > > > > > > > > Thanks, > > > > > dou. > > > > > > > > > > The debugging message with '-D': > > > > > > > > And what's the debugging printing when trigger crash by sysrq? > > > > > > > > > > kdump: dump target is /dev/vda2 > > > kdump: saving to /sysroot//var/crash/127.0.0.1-2018-02-07-07:31:56/ > > > [2.751352] EXT4-fs (vda2): re-mounted. Opts: data=ordered > > > kdump: saving vmcore-dmesg.txt > > > kdump: saving vmcore-dmesg.txt complete > > > kdump: saving vmcore > > > sadump: does not have partition header > > > sadump: read dump device as unknown format > > > sadump: unknown format > > > LOAD (0) > > >phys_start : 100 > > >phys_end : 2a86000 > > >virt_start : 8100 > > >virt_end : 82a86000 > > > LOAD (1) > > >phys_start : 1000 > > >phys_end : 9fc00 > > >virt_start : 88001000 > > >virt_end : 8809fc00 > > > LOAD (2) > > >phys_start : 10 > > >phys_end : 1300 > > >virt_start : 8810 > > >virt_end : 88001300 > > > LOAD (3) > > >phys_start : 3300 > > >phys_end : 7ffd7000 > > >virt_start :
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
Hi Baoquan, At 02/07/2018 08:45 PM, Baoquan He wrote: On 02/07/18 at 08:34pm, Dou Liyang wrote: At 02/07/2018 08:27 PM, Baoquan He wrote: On 02/07/18 at 08:17pm, Dou Liyang wrote: Hi Baoquan, At 02/07/2018 08:08 PM, Baoquan He wrote: On 02/07/18 at 08:00pm, Dou Liyang wrote: Hi Kirill,Mike At 02/07/2018 06:45 PM, Mike Galbraith wrote: On Wed, 2018-02-07 at 13:41 +0300, Kirill A. Shutemov wrote: On Wed, Feb 07, 2018 at 05:25:05PM +0800, Dou Liyang wrote: Hi All, I met the makedumpfile failed in the upstream kernel which contained this patch. Did I missed something else? None I'm aware of. Is there a reason to suspect that the issue is related to the bug this patch fixed? I did a contrastive test by my colleagues Indoh's suggestion. OK, I may get the reason. kaslr is enabled, right? You can try to I add 'nokaslr' to disable the KASLR feature. # cat /proc/cmdline BOOT_IMAGE=/vmlinuz-4.15.0+ root=UUID=10f10326-c923-4098-86aa-afed5c54ee0b ro crashkernel=512M rhgb console=tty0 console=ttyS0 nokaslr LANG=en_US.UTF-8 disable kaslr and try them again. Because phys_base and kaslr_offset are got from vmlinux, while these are generated at compiling time. Just a guess. Oh, I will recompile the kernel with KASLR disabled in .config. Thanks, dou. Revert your two commits: commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 Author: Kirill A. ShutemovDate: Fri Sep 29 17:08:16 2017 +0300 commit 629a359bdb0e0652a8227b4ff3125431995fec6e Author: Kirill A. Shutemov Date: Tue Nov 7 11:33:37 2017 +0300 ...and keep others unchanged, the makedumpfile works well. Still works fine for me with .today. Box is only 16GB desktop box though. Btw, In the upstream kernel which contained this patch, I did two tests: 1) use the makedumpfile as core_collector in /etc/kdump.conf, then trigger the process of kdump by echo 1 >/proc/sysrq-trigger, the makedumpfile works well and I can get the vmcore file. ..It is OK 2) use cp as core_collector, do the same operation to get the vmcore file. then use makedumpfile to do like above: [douly@localhost code]$ ./makedumpfile -d 31 --message-level 31 -x vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ Oh, then please ignore my previous comment. Adding '-D' can give more debugging message. I added '-D', Just like before, no more debugging message: BTW, I use crash to analyze the vmcore file created by 'cp' command. ./crash ../makedumpfile/code/vmcore_4.15+_from_cp_command ../makedumpfile/code/vmlinux_4.15+ the crash works well, It's so interesting. Thanks, dou. The debugging message with '-D': And what's the debugging printing when trigger crash by sysrq? kdump: dump target is /dev/vda2 kdump: saving to /sysroot//var/crash/127.0.0.1-2018-02-07-07:31:56/ [2.751352] EXT4-fs (vda2): re-mounted. Opts: data=ordered kdump: saving vmcore-dmesg.txt kdump: saving vmcore-dmesg.txt complete kdump: saving vmcore sadump: does not have partition header sadump: read dump device as unknown format sadump: unknown format LOAD (0) phys_start : 100 phys_end : 2a86000 virt_start : 8100 virt_end : 82a86000 LOAD (1) phys_start : 1000 phys_end : 9fc00 virt_start : 88001000 virt_end : 8809fc00 LOAD (2) phys_start : 10 phys_end : 1300 virt_start : 8810 virt_end : 88001300 LOAD (3) phys_start : 3300 phys_end : 7ffd7000 virt_start : 88003300 virt_end : 88007ffd7000 Linux kdump page_size: 4096 max_mapnr: 7ffd7 Buffer size for the cyclic mode: 131061 num of NODEs : 1 Memory type : SPARSEMEM_EX mem_map (0) mem_map: ea00 pfn_start : 0 pfn_end: 8000 mem_map (1) mem_map: ea20 pfn_start : 8000 pfn_end: 1 mem_map (2) mem_map: ea40 pfn_start : 1 pfn_end: 18000 mem_map (3) mem_map: ea60 pfn_start : 18000 pfn_end: 2 mem_map (4) mem_map: ea80 pfn_start : 2 pfn_end: 28000 mem_map (5) mem_map: eaa0 pfn_start : 28000 pfn_end: 3 mem_map (6) mem_map: eac0 pfn_start : 3 pfn_end: 38000 mem_map (7) mem_map: eae0 pfn_start : 38000 pfn_end: 4 mem_map (8) mem_map: ea000100 pfn_start : 4 pfn_end: 48000 mem_map (9) mem_map: ea000120 pfn_start : 48000 pfn_end: 5 mem_map (10) mem_map: ea000140 pfn_start : 5 pfn_end: 58000 mem_map (11) mem_map: ea000160 pfn_start : 58000 pfn_end: 6 mem_map (12) mem_map: ea000180 pfn_start : 6 pfn_end: 68000 mem_map (13) mem_map: ea0001a0 pfn_start :
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
Hi Baoquan, At 02/07/2018 08:45 PM, Baoquan He wrote: On 02/07/18 at 08:34pm, Dou Liyang wrote: At 02/07/2018 08:27 PM, Baoquan He wrote: On 02/07/18 at 08:17pm, Dou Liyang wrote: Hi Baoquan, At 02/07/2018 08:08 PM, Baoquan He wrote: On 02/07/18 at 08:00pm, Dou Liyang wrote: Hi Kirill,Mike At 02/07/2018 06:45 PM, Mike Galbraith wrote: On Wed, 2018-02-07 at 13:41 +0300, Kirill A. Shutemov wrote: On Wed, Feb 07, 2018 at 05:25:05PM +0800, Dou Liyang wrote: Hi All, I met the makedumpfile failed in the upstream kernel which contained this patch. Did I missed something else? None I'm aware of. Is there a reason to suspect that the issue is related to the bug this patch fixed? I did a contrastive test by my colleagues Indoh's suggestion. OK, I may get the reason. kaslr is enabled, right? You can try to I add 'nokaslr' to disable the KASLR feature. # cat /proc/cmdline BOOT_IMAGE=/vmlinuz-4.15.0+ root=UUID=10f10326-c923-4098-86aa-afed5c54ee0b ro crashkernel=512M rhgb console=tty0 console=ttyS0 nokaslr LANG=en_US.UTF-8 disable kaslr and try them again. Because phys_base and kaslr_offset are got from vmlinux, while these are generated at compiling time. Just a guess. Oh, I will recompile the kernel with KASLR disabled in .config. Thanks, dou. Revert your two commits: commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 Author: Kirill A. Shutemov Date: Fri Sep 29 17:08:16 2017 +0300 commit 629a359bdb0e0652a8227b4ff3125431995fec6e Author: Kirill A. Shutemov Date: Tue Nov 7 11:33:37 2017 +0300 ...and keep others unchanged, the makedumpfile works well. Still works fine for me with .today. Box is only 16GB desktop box though. Btw, In the upstream kernel which contained this patch, I did two tests: 1) use the makedumpfile as core_collector in /etc/kdump.conf, then trigger the process of kdump by echo 1 >/proc/sysrq-trigger, the makedumpfile works well and I can get the vmcore file. ..It is OK 2) use cp as core_collector, do the same operation to get the vmcore file. then use makedumpfile to do like above: [douly@localhost code]$ ./makedumpfile -d 31 --message-level 31 -x vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ Oh, then please ignore my previous comment. Adding '-D' can give more debugging message. I added '-D', Just like before, no more debugging message: BTW, I use crash to analyze the vmcore file created by 'cp' command. ./crash ../makedumpfile/code/vmcore_4.15+_from_cp_command ../makedumpfile/code/vmlinux_4.15+ the crash works well, It's so interesting. Thanks, dou. The debugging message with '-D': And what's the debugging printing when trigger crash by sysrq? kdump: dump target is /dev/vda2 kdump: saving to /sysroot//var/crash/127.0.0.1-2018-02-07-07:31:56/ [2.751352] EXT4-fs (vda2): re-mounted. Opts: data=ordered kdump: saving vmcore-dmesg.txt kdump: saving vmcore-dmesg.txt complete kdump: saving vmcore sadump: does not have partition header sadump: read dump device as unknown format sadump: unknown format LOAD (0) phys_start : 100 phys_end : 2a86000 virt_start : 8100 virt_end : 82a86000 LOAD (1) phys_start : 1000 phys_end : 9fc00 virt_start : 88001000 virt_end : 8809fc00 LOAD (2) phys_start : 10 phys_end : 1300 virt_start : 8810 virt_end : 88001300 LOAD (3) phys_start : 3300 phys_end : 7ffd7000 virt_start : 88003300 virt_end : 88007ffd7000 Linux kdump page_size: 4096 max_mapnr: 7ffd7 Buffer size for the cyclic mode: 131061 num of NODEs : 1 Memory type : SPARSEMEM_EX mem_map (0) mem_map: ea00 pfn_start : 0 pfn_end: 8000 mem_map (1) mem_map: ea20 pfn_start : 8000 pfn_end: 1 mem_map (2) mem_map: ea40 pfn_start : 1 pfn_end: 18000 mem_map (3) mem_map: ea60 pfn_start : 18000 pfn_end: 2 mem_map (4) mem_map: ea80 pfn_start : 2 pfn_end: 28000 mem_map (5) mem_map: eaa0 pfn_start : 28000 pfn_end: 3 mem_map (6) mem_map: eac0 pfn_start : 3 pfn_end: 38000 mem_map (7) mem_map: eae0 pfn_start : 38000 pfn_end: 4 mem_map (8) mem_map: ea000100 pfn_start : 4 pfn_end: 48000 mem_map (9) mem_map: ea000120 pfn_start : 48000 pfn_end: 5 mem_map (10) mem_map: ea000140 pfn_start : 5 pfn_end: 58000 mem_map (11) mem_map: ea000160 pfn_start : 58000 pfn_end: 6 mem_map (12) mem_map: ea000180 pfn_start : 6 pfn_end: 68000 mem_map (13) mem_map: ea0001a0 pfn_start : 68000 pfn_end: 7 mem_map (14) mem_map:
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On 02/07/18 at 08:34pm, Dou Liyang wrote: > > > At 02/07/2018 08:27 PM, Baoquan He wrote: > > On 02/07/18 at 08:17pm, Dou Liyang wrote: > > > Hi Baoquan, > > > > > > At 02/07/2018 08:08 PM, Baoquan He wrote: > > > > On 02/07/18 at 08:00pm, Dou Liyang wrote: > > > > > Hi Kirill,Mike > > > > > > > > > > At 02/07/2018 06:45 PM, Mike Galbraith wrote: > > > > > > On Wed, 2018-02-07 at 13:41 +0300, Kirill A. Shutemov wrote: > > > > > > > On Wed, Feb 07, 2018 at 05:25:05PM +0800, Dou Liyang wrote: > > > > > > > > Hi All, > > > > > > > > > > > > > > > > I met the makedumpfile failed in the upstream kernel which > > > > > > > > contained > > > > > > > > this patch. Did I missed something else? > > > > > > > > > > > > > > None I'm aware of. > > > > > > > > > > > > > > Is there a reason to suspect that the issue is related to the bug > > > > > > > this patch > > > > > > > fixed? > > > > > > > > > > > > > > > > I did a contrastive test by my colleagues Indoh's suggestion. OK, I may get the reason. kaslr is enabled, right? You can try to disable kaslr and try them again. Because phys_base and kaslr_offset are got from vmlinux, while these are generated at compiling time. Just a guess. > > > > > > > > > > Revert your two commits: > > > > > > > > > > commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 > > > > > Author: Kirill A. Shutemov> > > > > Date: Fri Sep 29 17:08:16 2017 +0300 > > > > > > > > > > commit 629a359bdb0e0652a8227b4ff3125431995fec6e > > > > > Author: Kirill A. Shutemov > > > > > Date: Tue Nov 7 11:33:37 2017 +0300 > > > > > > > > > > ...and keep others unchanged, the makedumpfile works well. > > > > > > > > > > > Still works fine for me with .today. Box is only 16GB desktop box > > > > > > though. > > > > > > > > > > > Btw, In the upstream kernel which contained this patch, I did two > > > > > tests: > > > > > > > > > >1) use the makedumpfile as core_collector in /etc/kdump.conf, then > > > > > trigger the process of kdump by echo 1 >/proc/sysrq-trigger, the > > > > > makedumpfile works well and I can get the vmcore file. > > > > > > > > > >..It is OK > > > > > > > > > >2) use cp as core_collector, do the same operation to get the > > > > > vmcore file. > > > > > then use makedumpfile to do like above: > > > > > > > > > > [douly@localhost code]$ ./makedumpfile -d 31 --message-level 31 > > > > > -x > > > > > vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ > > > > > > > > Oh, then please ignore my previous comment. Adding '-D' can give more > > > > debugging message. > > > > > > I added '-D', Just like before, no more debugging message: > > > > > > BTW, I use crash to analyze the vmcore file created by 'cp' command. > > > > > > ./crash ../makedumpfile/code/vmcore_4.15+_from_cp_command > > > ../makedumpfile/code/vmlinux_4.15+ > > > > > > the crash works well, It's so interesting. > > > > > > Thanks, > > > dou. > > > > > > The debugging message with '-D': > > > > And what's the debugging printing when trigger crash by sysrq? > > > > kdump: dump target is /dev/vda2 > kdump: saving to /sysroot//var/crash/127.0.0.1-2018-02-07-07:31:56/ > [2.751352] EXT4-fs (vda2): re-mounted. Opts: data=ordered > kdump: saving vmcore-dmesg.txt > kdump: saving vmcore-dmesg.txt complete > kdump: saving vmcore > sadump: does not have partition header > sadump: read dump device as unknown format > sadump: unknown format > LOAD (0) > phys_start : 100 > phys_end : 2a86000 > virt_start : 8100 > virt_end : 82a86000 > LOAD (1) > phys_start : 1000 > phys_end : 9fc00 > virt_start : 88001000 > virt_end : 8809fc00 > LOAD (2) > phys_start : 10 > phys_end : 1300 > virt_start : 8810 > virt_end : 88001300 > LOAD (3) > phys_start : 3300 > phys_end : 7ffd7000 > virt_start : 88003300 > virt_end : 88007ffd7000 > Linux kdump > page_size: 4096 > > max_mapnr: 7ffd7 > > Buffer size for the cyclic mode: 131061 > > num of NODEs : 1 > > > Memory type : SPARSEMEM_EX > > mem_map (0) > mem_map: ea00 > pfn_start : 0 > pfn_end: 8000 > mem_map (1) > mem_map: ea20 > pfn_start : 8000 > pfn_end: 1 > mem_map (2) > mem_map: ea40 > pfn_start : 1 > pfn_end: 18000 > mem_map (3) > mem_map: ea60 > pfn_start : 18000 > pfn_end: 2 > mem_map (4) > mem_map: ea80 > pfn_start : 2 > pfn_end: 28000 > mem_map (5) > mem_map: eaa0 > pfn_start : 28000 > pfn_end: 3 > mem_map (6) > mem_map: eac0 > pfn_start : 3 > pfn_end: 38000 > mem_map (7) > mem_map: eae0 > pfn_start : 38000 > pfn_end: 4 > mem_map (8) > mem_map: ea000100 > pfn_start :
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On 02/07/18 at 08:34pm, Dou Liyang wrote: > > > At 02/07/2018 08:27 PM, Baoquan He wrote: > > On 02/07/18 at 08:17pm, Dou Liyang wrote: > > > Hi Baoquan, > > > > > > At 02/07/2018 08:08 PM, Baoquan He wrote: > > > > On 02/07/18 at 08:00pm, Dou Liyang wrote: > > > > > Hi Kirill,Mike > > > > > > > > > > At 02/07/2018 06:45 PM, Mike Galbraith wrote: > > > > > > On Wed, 2018-02-07 at 13:41 +0300, Kirill A. Shutemov wrote: > > > > > > > On Wed, Feb 07, 2018 at 05:25:05PM +0800, Dou Liyang wrote: > > > > > > > > Hi All, > > > > > > > > > > > > > > > > I met the makedumpfile failed in the upstream kernel which > > > > > > > > contained > > > > > > > > this patch. Did I missed something else? > > > > > > > > > > > > > > None I'm aware of. > > > > > > > > > > > > > > Is there a reason to suspect that the issue is related to the bug > > > > > > > this patch > > > > > > > fixed? > > > > > > > > > > > > > > > > I did a contrastive test by my colleagues Indoh's suggestion. OK, I may get the reason. kaslr is enabled, right? You can try to disable kaslr and try them again. Because phys_base and kaslr_offset are got from vmlinux, while these are generated at compiling time. Just a guess. > > > > > > > > > > Revert your two commits: > > > > > > > > > > commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 > > > > > Author: Kirill A. Shutemov > > > > > Date: Fri Sep 29 17:08:16 2017 +0300 > > > > > > > > > > commit 629a359bdb0e0652a8227b4ff3125431995fec6e > > > > > Author: Kirill A. Shutemov > > > > > Date: Tue Nov 7 11:33:37 2017 +0300 > > > > > > > > > > ...and keep others unchanged, the makedumpfile works well. > > > > > > > > > > > Still works fine for me with .today. Box is only 16GB desktop box > > > > > > though. > > > > > > > > > > > Btw, In the upstream kernel which contained this patch, I did two > > > > > tests: > > > > > > > > > >1) use the makedumpfile as core_collector in /etc/kdump.conf, then > > > > > trigger the process of kdump by echo 1 >/proc/sysrq-trigger, the > > > > > makedumpfile works well and I can get the vmcore file. > > > > > > > > > >..It is OK > > > > > > > > > >2) use cp as core_collector, do the same operation to get the > > > > > vmcore file. > > > > > then use makedumpfile to do like above: > > > > > > > > > > [douly@localhost code]$ ./makedumpfile -d 31 --message-level 31 > > > > > -x > > > > > vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ > > > > > > > > Oh, then please ignore my previous comment. Adding '-D' can give more > > > > debugging message. > > > > > > I added '-D', Just like before, no more debugging message: > > > > > > BTW, I use crash to analyze the vmcore file created by 'cp' command. > > > > > > ./crash ../makedumpfile/code/vmcore_4.15+_from_cp_command > > > ../makedumpfile/code/vmlinux_4.15+ > > > > > > the crash works well, It's so interesting. > > > > > > Thanks, > > > dou. > > > > > > The debugging message with '-D': > > > > And what's the debugging printing when trigger crash by sysrq? > > > > kdump: dump target is /dev/vda2 > kdump: saving to /sysroot//var/crash/127.0.0.1-2018-02-07-07:31:56/ > [2.751352] EXT4-fs (vda2): re-mounted. Opts: data=ordered > kdump: saving vmcore-dmesg.txt > kdump: saving vmcore-dmesg.txt complete > kdump: saving vmcore > sadump: does not have partition header > sadump: read dump device as unknown format > sadump: unknown format > LOAD (0) > phys_start : 100 > phys_end : 2a86000 > virt_start : 8100 > virt_end : 82a86000 > LOAD (1) > phys_start : 1000 > phys_end : 9fc00 > virt_start : 88001000 > virt_end : 8809fc00 > LOAD (2) > phys_start : 10 > phys_end : 1300 > virt_start : 8810 > virt_end : 88001300 > LOAD (3) > phys_start : 3300 > phys_end : 7ffd7000 > virt_start : 88003300 > virt_end : 88007ffd7000 > Linux kdump > page_size: 4096 > > max_mapnr: 7ffd7 > > Buffer size for the cyclic mode: 131061 > > num of NODEs : 1 > > > Memory type : SPARSEMEM_EX > > mem_map (0) > mem_map: ea00 > pfn_start : 0 > pfn_end: 8000 > mem_map (1) > mem_map: ea20 > pfn_start : 8000 > pfn_end: 1 > mem_map (2) > mem_map: ea40 > pfn_start : 1 > pfn_end: 18000 > mem_map (3) > mem_map: ea60 > pfn_start : 18000 > pfn_end: 2 > mem_map (4) > mem_map: ea80 > pfn_start : 2 > pfn_end: 28000 > mem_map (5) > mem_map: eaa0 > pfn_start : 28000 > pfn_end: 3 > mem_map (6) > mem_map: eac0 > pfn_start : 3 > pfn_end: 38000 > mem_map (7) > mem_map: eae0 > pfn_start : 38000 > pfn_end: 4 > mem_map (8) > mem_map: ea000100 > pfn_start : 4 > pfn_end: 48000 > mem_map (9) > mem_map:
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
At 02/07/2018 08:27 PM, Baoquan He wrote: On 02/07/18 at 08:17pm, Dou Liyang wrote: Hi Baoquan, At 02/07/2018 08:08 PM, Baoquan He wrote: On 02/07/18 at 08:00pm, Dou Liyang wrote: Hi Kirill,Mike At 02/07/2018 06:45 PM, Mike Galbraith wrote: On Wed, 2018-02-07 at 13:41 +0300, Kirill A. Shutemov wrote: On Wed, Feb 07, 2018 at 05:25:05PM +0800, Dou Liyang wrote: Hi All, I met the makedumpfile failed in the upstream kernel which contained this patch. Did I missed something else? None I'm aware of. Is there a reason to suspect that the issue is related to the bug this patch fixed? I did a contrastive test by my colleagues Indoh's suggestion. Revert your two commits: commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 Author: Kirill A. ShutemovDate: Fri Sep 29 17:08:16 2017 +0300 commit 629a359bdb0e0652a8227b4ff3125431995fec6e Author: Kirill A. Shutemov Date: Tue Nov 7 11:33:37 2017 +0300 ...and keep others unchanged, the makedumpfile works well. Still works fine for me with .today. Box is only 16GB desktop box though. Btw, In the upstream kernel which contained this patch, I did two tests: 1) use the makedumpfile as core_collector in /etc/kdump.conf, then trigger the process of kdump by echo 1 >/proc/sysrq-trigger, the makedumpfile works well and I can get the vmcore file. ..It is OK 2) use cp as core_collector, do the same operation to get the vmcore file. then use makedumpfile to do like above: [douly@localhost code]$ ./makedumpfile -d 31 --message-level 31 -x vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ Oh, then please ignore my previous comment. Adding '-D' can give more debugging message. I added '-D', Just like before, no more debugging message: BTW, I use crash to analyze the vmcore file created by 'cp' command. ./crash ../makedumpfile/code/vmcore_4.15+_from_cp_command ../makedumpfile/code/vmlinux_4.15+ the crash works well, It's so interesting. Thanks, dou. The debugging message with '-D': And what's the debugging printing when trigger crash by sysrq? kdump: dump target is /dev/vda2 kdump: saving to /sysroot//var/crash/127.0.0.1-2018-02-07-07:31:56/ [2.751352] EXT4-fs (vda2): re-mounted. Opts: data=ordered kdump: saving vmcore-dmesg.txt kdump: saving vmcore-dmesg.txt complete kdump: saving vmcore sadump: does not have partition header sadump: read dump device as unknown format sadump: unknown format LOAD (0) phys_start : 100 phys_end : 2a86000 virt_start : 8100 virt_end : 82a86000 LOAD (1) phys_start : 1000 phys_end : 9fc00 virt_start : 88001000 virt_end : 8809fc00 LOAD (2) phys_start : 10 phys_end : 1300 virt_start : 8810 virt_end : 88001300 LOAD (3) phys_start : 3300 phys_end : 7ffd7000 virt_start : 88003300 virt_end : 88007ffd7000 Linux kdump page_size: 4096 max_mapnr: 7ffd7 Buffer size for the cyclic mode: 131061 num of NODEs : 1 Memory type : SPARSEMEM_EX mem_map (0) mem_map: ea00 pfn_start : 0 pfn_end: 8000 mem_map (1) mem_map: ea20 pfn_start : 8000 pfn_end: 1 mem_map (2) mem_map: ea40 pfn_start : 1 pfn_end: 18000 mem_map (3) mem_map: ea60 pfn_start : 18000 pfn_end: 2 mem_map (4) mem_map: ea80 pfn_start : 2 pfn_end: 28000 mem_map (5) mem_map: eaa0 pfn_start : 28000 pfn_end: 3 mem_map (6) mem_map: eac0 pfn_start : 3 pfn_end: 38000 mem_map (7) mem_map: eae0 pfn_start : 38000 pfn_end: 4 mem_map (8) mem_map: ea000100 pfn_start : 4 pfn_end: 48000 mem_map (9) mem_map: ea000120 pfn_start : 48000 pfn_end: 5 mem_map (10) mem_map: ea000140 pfn_start : 5 pfn_end: 58000 mem_map (11) mem_map: ea000160 pfn_start : 58000 pfn_end: 6 mem_map (12) mem_map: ea000180 pfn_start : 6 pfn_end: 68000 mem_map (13) mem_map: ea0001a0 pfn_start : 68000 pfn_end: 7 mem_map (14) mem_map: ea0001c0 pfn_start : 7 pfn_end: 78000 mem_map (15) mem_map: ea0001e0 pfn_start : 78000 pfn_end: 7ffd7 mmap() is available on the kernel. Copying data : [100.0 %] - eta: 0s Writing erase info... offset_eraseinfo: 9567fb0, size_eraseinfo: 0 kdump: saving vmcore complete Thanks, dou [douly@localhost code]$ ./makedumpfile -D -d 31 --message-level 31 -x vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ sadump: does not have partition header sadump: read dump device as unknown format sadump: unknown format LOAD (0) phys_start : 100
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
At 02/07/2018 08:27 PM, Baoquan He wrote: On 02/07/18 at 08:17pm, Dou Liyang wrote: Hi Baoquan, At 02/07/2018 08:08 PM, Baoquan He wrote: On 02/07/18 at 08:00pm, Dou Liyang wrote: Hi Kirill,Mike At 02/07/2018 06:45 PM, Mike Galbraith wrote: On Wed, 2018-02-07 at 13:41 +0300, Kirill A. Shutemov wrote: On Wed, Feb 07, 2018 at 05:25:05PM +0800, Dou Liyang wrote: Hi All, I met the makedumpfile failed in the upstream kernel which contained this patch. Did I missed something else? None I'm aware of. Is there a reason to suspect that the issue is related to the bug this patch fixed? I did a contrastive test by my colleagues Indoh's suggestion. Revert your two commits: commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 Author: Kirill A. Shutemov Date: Fri Sep 29 17:08:16 2017 +0300 commit 629a359bdb0e0652a8227b4ff3125431995fec6e Author: Kirill A. Shutemov Date: Tue Nov 7 11:33:37 2017 +0300 ...and keep others unchanged, the makedumpfile works well. Still works fine for me with .today. Box is only 16GB desktop box though. Btw, In the upstream kernel which contained this patch, I did two tests: 1) use the makedumpfile as core_collector in /etc/kdump.conf, then trigger the process of kdump by echo 1 >/proc/sysrq-trigger, the makedumpfile works well and I can get the vmcore file. ..It is OK 2) use cp as core_collector, do the same operation to get the vmcore file. then use makedumpfile to do like above: [douly@localhost code]$ ./makedumpfile -d 31 --message-level 31 -x vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ Oh, then please ignore my previous comment. Adding '-D' can give more debugging message. I added '-D', Just like before, no more debugging message: BTW, I use crash to analyze the vmcore file created by 'cp' command. ./crash ../makedumpfile/code/vmcore_4.15+_from_cp_command ../makedumpfile/code/vmlinux_4.15+ the crash works well, It's so interesting. Thanks, dou. The debugging message with '-D': And what's the debugging printing when trigger crash by sysrq? kdump: dump target is /dev/vda2 kdump: saving to /sysroot//var/crash/127.0.0.1-2018-02-07-07:31:56/ [2.751352] EXT4-fs (vda2): re-mounted. Opts: data=ordered kdump: saving vmcore-dmesg.txt kdump: saving vmcore-dmesg.txt complete kdump: saving vmcore sadump: does not have partition header sadump: read dump device as unknown format sadump: unknown format LOAD (0) phys_start : 100 phys_end : 2a86000 virt_start : 8100 virt_end : 82a86000 LOAD (1) phys_start : 1000 phys_end : 9fc00 virt_start : 88001000 virt_end : 8809fc00 LOAD (2) phys_start : 10 phys_end : 1300 virt_start : 8810 virt_end : 88001300 LOAD (3) phys_start : 3300 phys_end : 7ffd7000 virt_start : 88003300 virt_end : 88007ffd7000 Linux kdump page_size: 4096 max_mapnr: 7ffd7 Buffer size for the cyclic mode: 131061 num of NODEs : 1 Memory type : SPARSEMEM_EX mem_map (0) mem_map: ea00 pfn_start : 0 pfn_end: 8000 mem_map (1) mem_map: ea20 pfn_start : 8000 pfn_end: 1 mem_map (2) mem_map: ea40 pfn_start : 1 pfn_end: 18000 mem_map (3) mem_map: ea60 pfn_start : 18000 pfn_end: 2 mem_map (4) mem_map: ea80 pfn_start : 2 pfn_end: 28000 mem_map (5) mem_map: eaa0 pfn_start : 28000 pfn_end: 3 mem_map (6) mem_map: eac0 pfn_start : 3 pfn_end: 38000 mem_map (7) mem_map: eae0 pfn_start : 38000 pfn_end: 4 mem_map (8) mem_map: ea000100 pfn_start : 4 pfn_end: 48000 mem_map (9) mem_map: ea000120 pfn_start : 48000 pfn_end: 5 mem_map (10) mem_map: ea000140 pfn_start : 5 pfn_end: 58000 mem_map (11) mem_map: ea000160 pfn_start : 58000 pfn_end: 6 mem_map (12) mem_map: ea000180 pfn_start : 6 pfn_end: 68000 mem_map (13) mem_map: ea0001a0 pfn_start : 68000 pfn_end: 7 mem_map (14) mem_map: ea0001c0 pfn_start : 7 pfn_end: 78000 mem_map (15) mem_map: ea0001e0 pfn_start : 78000 pfn_end: 7ffd7 mmap() is available on the kernel. Copying data : [100.0 %] - eta: 0s Writing erase info... offset_eraseinfo: 9567fb0, size_eraseinfo: 0 kdump: saving vmcore complete Thanks, dou [douly@localhost code]$ ./makedumpfile -D -d 31 --message-level 31 -x vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ sadump: does not have partition header sadump: read dump device as unknown format sadump: unknown format LOAD (0) phys_start : 100 phys_end : 2a86000 virt_start : 8100
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On 02/07/18 at 08:17pm, Dou Liyang wrote: > Hi Baoquan, > > At 02/07/2018 08:08 PM, Baoquan He wrote: > > On 02/07/18 at 08:00pm, Dou Liyang wrote: > > > Hi Kirill,Mike > > > > > > At 02/07/2018 06:45 PM, Mike Galbraith wrote: > > > > On Wed, 2018-02-07 at 13:41 +0300, Kirill A. Shutemov wrote: > > > > > On Wed, Feb 07, 2018 at 05:25:05PM +0800, Dou Liyang wrote: > > > > > > Hi All, > > > > > > > > > > > > I met the makedumpfile failed in the upstream kernel which contained > > > > > > this patch. Did I missed something else? > > > > > > > > > > None I'm aware of. > > > > > > > > > > Is there a reason to suspect that the issue is related to the bug > > > > > this patch > > > > > fixed? > > > > > > > > > > I did a contrastive test by my colleagues Indoh's suggestion. > > > > > > Revert your two commits: > > > > > > commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 > > > Author: Kirill A. Shutemov> > > Date: Fri Sep 29 17:08:16 2017 +0300 > > > > > > commit 629a359bdb0e0652a8227b4ff3125431995fec6e > > > Author: Kirill A. Shutemov > > > Date: Tue Nov 7 11:33:37 2017 +0300 > > > > > > ...and keep others unchanged, the makedumpfile works well. > > > > > > > Still works fine for me with .today. Box is only 16GB desktop box > > > > though. > > > > > > > Btw, In the upstream kernel which contained this patch, I did two tests: > > > > > > 1) use the makedumpfile as core_collector in /etc/kdump.conf, then > > > trigger the process of kdump by echo 1 >/proc/sysrq-trigger, the > > > makedumpfile works well and I can get the vmcore file. > > > > > > ..It is OK > > > > > > 2) use cp as core_collector, do the same operation to get the vmcore > > > file. > > > then use makedumpfile to do like above: > > > > > > [douly@localhost code]$ ./makedumpfile -d 31 --message-level 31 -x > > > vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ > > > > Oh, then please ignore my previous comment. Adding '-D' can give more > > debugging message. > > I added '-D', Just like before, no more debugging message: > > BTW, I use crash to analyze the vmcore file created by 'cp' command. > >./crash ../makedumpfile/code/vmcore_4.15+_from_cp_command > ../makedumpfile/code/vmlinux_4.15+ > > the crash works well, It's so interesting. > > Thanks, > dou. > > The debugging message with '-D': And what's the debugging printing when trigger crash by sysrq? > > [douly@localhost code]$ ./makedumpfile -D -d 31 --message-level 31 -x > vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ > sadump: does not have partition header > sadump: read dump device as unknown format > sadump: unknown format > LOAD (0) > phys_start : 100 > phys_end : 2a86000 > virt_start : 8100 > virt_end : 82a86000 > LOAD (1) > phys_start : 1000 > phys_end : 9fc00 > virt_start : 88001000 > virt_end : 8809fc00 > LOAD (2) > phys_start : 10 > phys_end : 1300 > virt_start : 8810 > virt_end : 88001300 > LOAD (3) > phys_start : 3300 > phys_end : 7ffd7000 > virt_start : 88003300 > virt_end : 88007ffd7000 > Linux kdump > page_size: 4096 > > max_mapnr: 7ffd7 > > Buffer size for the cyclic mode: 131061 > The kernel version is not supported. > The makedumpfile operation may be incomplete. > > num of NODEs : 1 > > > Memory type : SPARSEMEM_EX > > mem_map (0) > mem_map: 88007ff26000 > pfn_start : 0 > pfn_end: 8000 > mem_map (1) > mem_map: 0 > pfn_start : 8000 > pfn_end: 1 > mem_map (2) > mem_map: 0 > pfn_start : 1 > pfn_end: 18000 > mem_map (3) > mem_map: 0 > pfn_start : 18000 > pfn_end: 2 > mem_map (4) > mem_map: 0 > pfn_start : 2 > pfn_end: 28000 > mem_map (5) > mem_map: 0 > pfn_start : 28000 > pfn_end: 3 > mem_map (6) > mem_map: 0 > pfn_start : 3 > pfn_end: 38000 > mem_map (7) > mem_map: 0 > pfn_start : 38000 > pfn_end: 4 > mem_map (8) > mem_map: 0 > pfn_start : 4 > pfn_end: 48000 > mem_map (9) > mem_map: 0 > pfn_start : 48000 > pfn_end: 5 > mem_map (10) > mem_map: 0 > pfn_start : 5 > pfn_end: 58000 > mem_map (11) > mem_map: 0 > pfn_start : 58000 > pfn_end: 6 > mem_map (12) > mem_map: 0 > pfn_start : 6 > pfn_end: 68000 > mem_map (13) > mem_map: 0 > pfn_start : 68000 > pfn_end: 7 > mem_map (14) > mem_map: 0 > pfn_start : 7 > pfn_end: 78000 > mem_map (15) > mem_map: 0 > pfn_start : 78000 > pfn_end: 7ffd7 > mmap() is available on the kernel. > Checking for memory holes : [100.0 %] | STEP > [Checking for memory holes ] : 0.14 seconds > __vtop4_x86_64: Can't get a valid pte. > readmem:
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On 02/07/18 at 08:17pm, Dou Liyang wrote: > Hi Baoquan, > > At 02/07/2018 08:08 PM, Baoquan He wrote: > > On 02/07/18 at 08:00pm, Dou Liyang wrote: > > > Hi Kirill,Mike > > > > > > At 02/07/2018 06:45 PM, Mike Galbraith wrote: > > > > On Wed, 2018-02-07 at 13:41 +0300, Kirill A. Shutemov wrote: > > > > > On Wed, Feb 07, 2018 at 05:25:05PM +0800, Dou Liyang wrote: > > > > > > Hi All, > > > > > > > > > > > > I met the makedumpfile failed in the upstream kernel which contained > > > > > > this patch. Did I missed something else? > > > > > > > > > > None I'm aware of. > > > > > > > > > > Is there a reason to suspect that the issue is related to the bug > > > > > this patch > > > > > fixed? > > > > > > > > > > I did a contrastive test by my colleagues Indoh's suggestion. > > > > > > Revert your two commits: > > > > > > commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 > > > Author: Kirill A. Shutemov > > > Date: Fri Sep 29 17:08:16 2017 +0300 > > > > > > commit 629a359bdb0e0652a8227b4ff3125431995fec6e > > > Author: Kirill A. Shutemov > > > Date: Tue Nov 7 11:33:37 2017 +0300 > > > > > > ...and keep others unchanged, the makedumpfile works well. > > > > > > > Still works fine for me with .today. Box is only 16GB desktop box > > > > though. > > > > > > > Btw, In the upstream kernel which contained this patch, I did two tests: > > > > > > 1) use the makedumpfile as core_collector in /etc/kdump.conf, then > > > trigger the process of kdump by echo 1 >/proc/sysrq-trigger, the > > > makedumpfile works well and I can get the vmcore file. > > > > > > ..It is OK > > > > > > 2) use cp as core_collector, do the same operation to get the vmcore > > > file. > > > then use makedumpfile to do like above: > > > > > > [douly@localhost code]$ ./makedumpfile -d 31 --message-level 31 -x > > > vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ > > > > Oh, then please ignore my previous comment. Adding '-D' can give more > > debugging message. > > I added '-D', Just like before, no more debugging message: > > BTW, I use crash to analyze the vmcore file created by 'cp' command. > >./crash ../makedumpfile/code/vmcore_4.15+_from_cp_command > ../makedumpfile/code/vmlinux_4.15+ > > the crash works well, It's so interesting. > > Thanks, > dou. > > The debugging message with '-D': And what's the debugging printing when trigger crash by sysrq? > > [douly@localhost code]$ ./makedumpfile -D -d 31 --message-level 31 -x > vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ > sadump: does not have partition header > sadump: read dump device as unknown format > sadump: unknown format > LOAD (0) > phys_start : 100 > phys_end : 2a86000 > virt_start : 8100 > virt_end : 82a86000 > LOAD (1) > phys_start : 1000 > phys_end : 9fc00 > virt_start : 88001000 > virt_end : 8809fc00 > LOAD (2) > phys_start : 10 > phys_end : 1300 > virt_start : 8810 > virt_end : 88001300 > LOAD (3) > phys_start : 3300 > phys_end : 7ffd7000 > virt_start : 88003300 > virt_end : 88007ffd7000 > Linux kdump > page_size: 4096 > > max_mapnr: 7ffd7 > > Buffer size for the cyclic mode: 131061 > The kernel version is not supported. > The makedumpfile operation may be incomplete. > > num of NODEs : 1 > > > Memory type : SPARSEMEM_EX > > mem_map (0) > mem_map: 88007ff26000 > pfn_start : 0 > pfn_end: 8000 > mem_map (1) > mem_map: 0 > pfn_start : 8000 > pfn_end: 1 > mem_map (2) > mem_map: 0 > pfn_start : 1 > pfn_end: 18000 > mem_map (3) > mem_map: 0 > pfn_start : 18000 > pfn_end: 2 > mem_map (4) > mem_map: 0 > pfn_start : 2 > pfn_end: 28000 > mem_map (5) > mem_map: 0 > pfn_start : 28000 > pfn_end: 3 > mem_map (6) > mem_map: 0 > pfn_start : 3 > pfn_end: 38000 > mem_map (7) > mem_map: 0 > pfn_start : 38000 > pfn_end: 4 > mem_map (8) > mem_map: 0 > pfn_start : 4 > pfn_end: 48000 > mem_map (9) > mem_map: 0 > pfn_start : 48000 > pfn_end: 5 > mem_map (10) > mem_map: 0 > pfn_start : 5 > pfn_end: 58000 > mem_map (11) > mem_map: 0 > pfn_start : 58000 > pfn_end: 6 > mem_map (12) > mem_map: 0 > pfn_start : 6 > pfn_end: 68000 > mem_map (13) > mem_map: 0 > pfn_start : 68000 > pfn_end: 7 > mem_map (14) > mem_map: 0 > pfn_start : 7 > pfn_end: 78000 > mem_map (15) > mem_map: 0 > pfn_start : 78000 > pfn_end: 7ffd7 > mmap() is available on the kernel. > Checking for memory holes : [100.0 %] | STEP > [Checking for memory holes ] : 0.14 seconds > __vtop4_x86_64: Can't get a valid pte. > readmem: Can't convert a virtual address(88007ffd7000) to physical >
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
Hi Baoquan, At 02/07/2018 08:08 PM, Baoquan He wrote: On 02/07/18 at 08:00pm, Dou Liyang wrote: Hi Kirill,Mike At 02/07/2018 06:45 PM, Mike Galbraith wrote: On Wed, 2018-02-07 at 13:41 +0300, Kirill A. Shutemov wrote: On Wed, Feb 07, 2018 at 05:25:05PM +0800, Dou Liyang wrote: Hi All, I met the makedumpfile failed in the upstream kernel which contained this patch. Did I missed something else? None I'm aware of. Is there a reason to suspect that the issue is related to the bug this patch fixed? I did a contrastive test by my colleagues Indoh's suggestion. Revert your two commits: commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 Author: Kirill A. ShutemovDate: Fri Sep 29 17:08:16 2017 +0300 commit 629a359bdb0e0652a8227b4ff3125431995fec6e Author: Kirill A. Shutemov Date: Tue Nov 7 11:33:37 2017 +0300 ...and keep others unchanged, the makedumpfile works well. Still works fine for me with .today. Box is only 16GB desktop box though. Btw, In the upstream kernel which contained this patch, I did two tests: 1) use the makedumpfile as core_collector in /etc/kdump.conf, then trigger the process of kdump by echo 1 >/proc/sysrq-trigger, the makedumpfile works well and I can get the vmcore file. ..It is OK 2) use cp as core_collector, do the same operation to get the vmcore file. then use makedumpfile to do like above: [douly@localhost code]$ ./makedumpfile -d 31 --message-level 31 -x vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ Oh, then please ignore my previous comment. Adding '-D' can give more debugging message. I added '-D', Just like before, no more debugging message: BTW, I use crash to analyze the vmcore file created by 'cp' command. ./crash ../makedumpfile/code/vmcore_4.15+_from_cp_command ../makedumpfile/code/vmlinux_4.15+ the crash works well, It's so interesting. Thanks, dou. The debugging message with '-D': [douly@localhost code]$ ./makedumpfile -D -d 31 --message-level 31 -x vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ sadump: does not have partition header sadump: read dump device as unknown format sadump: unknown format LOAD (0) phys_start : 100 phys_end : 2a86000 virt_start : 8100 virt_end : 82a86000 LOAD (1) phys_start : 1000 phys_end : 9fc00 virt_start : 88001000 virt_end : 8809fc00 LOAD (2) phys_start : 10 phys_end : 1300 virt_start : 8810 virt_end : 88001300 LOAD (3) phys_start : 3300 phys_end : 7ffd7000 virt_start : 88003300 virt_end : 88007ffd7000 Linux kdump page_size: 4096 max_mapnr: 7ffd7 Buffer size for the cyclic mode: 131061 The kernel version is not supported. The makedumpfile operation may be incomplete. num of NODEs : 1 Memory type : SPARSEMEM_EX mem_map (0) mem_map: 88007ff26000 pfn_start : 0 pfn_end: 8000 mem_map (1) mem_map: 0 pfn_start : 8000 pfn_end: 1 mem_map (2) mem_map: 0 pfn_start : 1 pfn_end: 18000 mem_map (3) mem_map: 0 pfn_start : 18000 pfn_end: 2 mem_map (4) mem_map: 0 pfn_start : 2 pfn_end: 28000 mem_map (5) mem_map: 0 pfn_start : 28000 pfn_end: 3 mem_map (6) mem_map: 0 pfn_start : 3 pfn_end: 38000 mem_map (7) mem_map: 0 pfn_start : 38000 pfn_end: 4 mem_map (8) mem_map: 0 pfn_start : 4 pfn_end: 48000 mem_map (9) mem_map: 0 pfn_start : 48000 pfn_end: 5 mem_map (10) mem_map: 0 pfn_start : 5 pfn_end: 58000 mem_map (11) mem_map: 0 pfn_start : 58000 pfn_end: 6 mem_map (12) mem_map: 0 pfn_start : 6 pfn_end: 68000 mem_map (13) mem_map: 0 pfn_start : 68000 pfn_end: 7 mem_map (14) mem_map: 0 pfn_start : 7 pfn_end: 78000 mem_map (15) mem_map: 0 pfn_start : 78000 pfn_end: 7ffd7 mmap() is available on the kernel. Checking for memory holes : [100.0 %] | STEP [Checking for memory holes ] : 0.14 seconds __vtop4_x86_64: Can't get a valid pte. readmem: Can't convert a virtual address(88007ffd7000) to physical address. readmem: type_addr: 0, addr:88007ffd7000, size:32768 __exclude_unnecessary_pages: Can't read the buffer of struct page. create_2nd_bitmap: Can't exclude unnecessary pages. Checking for memory holes : [100.0 %] \ STEP [Checking for memory holes ] : 0.06 seconds Checking for memory holes : [100.0 %] - STEP [Checking for memory holes ] : 0.04 seconds __vtop4_x86_64: Can't get a valid pte. readmem: Can't convert a virtual address(88007ffd7000) to physical address. readmem: type_addr: 0, addr:88007ffd7000, size:32768
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
Hi Baoquan, At 02/07/2018 08:08 PM, Baoquan He wrote: On 02/07/18 at 08:00pm, Dou Liyang wrote: Hi Kirill,Mike At 02/07/2018 06:45 PM, Mike Galbraith wrote: On Wed, 2018-02-07 at 13:41 +0300, Kirill A. Shutemov wrote: On Wed, Feb 07, 2018 at 05:25:05PM +0800, Dou Liyang wrote: Hi All, I met the makedumpfile failed in the upstream kernel which contained this patch. Did I missed something else? None I'm aware of. Is there a reason to suspect that the issue is related to the bug this patch fixed? I did a contrastive test by my colleagues Indoh's suggestion. Revert your two commits: commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 Author: Kirill A. Shutemov Date: Fri Sep 29 17:08:16 2017 +0300 commit 629a359bdb0e0652a8227b4ff3125431995fec6e Author: Kirill A. Shutemov Date: Tue Nov 7 11:33:37 2017 +0300 ...and keep others unchanged, the makedumpfile works well. Still works fine for me with .today. Box is only 16GB desktop box though. Btw, In the upstream kernel which contained this patch, I did two tests: 1) use the makedumpfile as core_collector in /etc/kdump.conf, then trigger the process of kdump by echo 1 >/proc/sysrq-trigger, the makedumpfile works well and I can get the vmcore file. ..It is OK 2) use cp as core_collector, do the same operation to get the vmcore file. then use makedumpfile to do like above: [douly@localhost code]$ ./makedumpfile -d 31 --message-level 31 -x vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ Oh, then please ignore my previous comment. Adding '-D' can give more debugging message. I added '-D', Just like before, no more debugging message: BTW, I use crash to analyze the vmcore file created by 'cp' command. ./crash ../makedumpfile/code/vmcore_4.15+_from_cp_command ../makedumpfile/code/vmlinux_4.15+ the crash works well, It's so interesting. Thanks, dou. The debugging message with '-D': [douly@localhost code]$ ./makedumpfile -D -d 31 --message-level 31 -x vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ sadump: does not have partition header sadump: read dump device as unknown format sadump: unknown format LOAD (0) phys_start : 100 phys_end : 2a86000 virt_start : 8100 virt_end : 82a86000 LOAD (1) phys_start : 1000 phys_end : 9fc00 virt_start : 88001000 virt_end : 8809fc00 LOAD (2) phys_start : 10 phys_end : 1300 virt_start : 8810 virt_end : 88001300 LOAD (3) phys_start : 3300 phys_end : 7ffd7000 virt_start : 88003300 virt_end : 88007ffd7000 Linux kdump page_size: 4096 max_mapnr: 7ffd7 Buffer size for the cyclic mode: 131061 The kernel version is not supported. The makedumpfile operation may be incomplete. num of NODEs : 1 Memory type : SPARSEMEM_EX mem_map (0) mem_map: 88007ff26000 pfn_start : 0 pfn_end: 8000 mem_map (1) mem_map: 0 pfn_start : 8000 pfn_end: 1 mem_map (2) mem_map: 0 pfn_start : 1 pfn_end: 18000 mem_map (3) mem_map: 0 pfn_start : 18000 pfn_end: 2 mem_map (4) mem_map: 0 pfn_start : 2 pfn_end: 28000 mem_map (5) mem_map: 0 pfn_start : 28000 pfn_end: 3 mem_map (6) mem_map: 0 pfn_start : 3 pfn_end: 38000 mem_map (7) mem_map: 0 pfn_start : 38000 pfn_end: 4 mem_map (8) mem_map: 0 pfn_start : 4 pfn_end: 48000 mem_map (9) mem_map: 0 pfn_start : 48000 pfn_end: 5 mem_map (10) mem_map: 0 pfn_start : 5 pfn_end: 58000 mem_map (11) mem_map: 0 pfn_start : 58000 pfn_end: 6 mem_map (12) mem_map: 0 pfn_start : 6 pfn_end: 68000 mem_map (13) mem_map: 0 pfn_start : 68000 pfn_end: 7 mem_map (14) mem_map: 0 pfn_start : 7 pfn_end: 78000 mem_map (15) mem_map: 0 pfn_start : 78000 pfn_end: 7ffd7 mmap() is available on the kernel. Checking for memory holes : [100.0 %] | STEP [Checking for memory holes ] : 0.14 seconds __vtop4_x86_64: Can't get a valid pte. readmem: Can't convert a virtual address(88007ffd7000) to physical address. readmem: type_addr: 0, addr:88007ffd7000, size:32768 __exclude_unnecessary_pages: Can't read the buffer of struct page. create_2nd_bitmap: Can't exclude unnecessary pages. Checking for memory holes : [100.0 %] \ STEP [Checking for memory holes ] : 0.06 seconds Checking for memory holes : [100.0 %] - STEP [Checking for memory holes ] : 0.04 seconds __vtop4_x86_64: Can't get a valid pte. readmem: Can't convert a virtual address(88007ffd7000) to physical address. readmem: type_addr: 0, addr:88007ffd7000, size:32768 __exclude_unnecessary_pages: Can't read the buffer of struct page. create_2nd_bitmap: Can't
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On 02/07/18 at 08:00pm, Dou Liyang wrote: > Hi Kirill,Mike > > At 02/07/2018 06:45 PM, Mike Galbraith wrote: > > On Wed, 2018-02-07 at 13:41 +0300, Kirill A. Shutemov wrote: > > > On Wed, Feb 07, 2018 at 05:25:05PM +0800, Dou Liyang wrote: > > > > Hi All, > > > > > > > > I met the makedumpfile failed in the upstream kernel which contained > > > > this patch. Did I missed something else? > > > > > > None I'm aware of. > > > > > > Is there a reason to suspect that the issue is related to the bug this > > > patch > > > fixed? > > > > I did a contrastive test by my colleagues Indoh's suggestion. > > Revert your two commits: > > commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 > Author: Kirill A. Shutemov> Date: Fri Sep 29 17:08:16 2017 +0300 > > commit 629a359bdb0e0652a8227b4ff3125431995fec6e > Author: Kirill A. Shutemov > Date: Tue Nov 7 11:33:37 2017 +0300 > > ...and keep others unchanged, the makedumpfile works well. > > > Still works fine for me with .today. Box is only 16GB desktop box though. > > > Btw, In the upstream kernel which contained this patch, I did two tests: > > 1) use the makedumpfile as core_collector in /etc/kdump.conf, then > trigger the process of kdump by echo 1 >/proc/sysrq-trigger, the > makedumpfile works well and I can get the vmcore file. > > ..It is OK > > 2) use cp as core_collector, do the same operation to get the vmcore file. > then use makedumpfile to do like above: > > [douly@localhost code]$ ./makedumpfile -d 31 --message-level 31 -x > vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ Oh, then please ignore my previous comment. Adding '-D' can give more debugging message. > > ..It causes makedumpfile failed. > > > Thanks, > dou. > > > -Mike > > > > > > > >
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On 02/07/18 at 08:00pm, Dou Liyang wrote: > Hi Kirill,Mike > > At 02/07/2018 06:45 PM, Mike Galbraith wrote: > > On Wed, 2018-02-07 at 13:41 +0300, Kirill A. Shutemov wrote: > > > On Wed, Feb 07, 2018 at 05:25:05PM +0800, Dou Liyang wrote: > > > > Hi All, > > > > > > > > I met the makedumpfile failed in the upstream kernel which contained > > > > this patch. Did I missed something else? > > > > > > None I'm aware of. > > > > > > Is there a reason to suspect that the issue is related to the bug this > > > patch > > > fixed? > > > > I did a contrastive test by my colleagues Indoh's suggestion. > > Revert your two commits: > > commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 > Author: Kirill A. Shutemov > Date: Fri Sep 29 17:08:16 2017 +0300 > > commit 629a359bdb0e0652a8227b4ff3125431995fec6e > Author: Kirill A. Shutemov > Date: Tue Nov 7 11:33:37 2017 +0300 > > ...and keep others unchanged, the makedumpfile works well. > > > Still works fine for me with .today. Box is only 16GB desktop box though. > > > Btw, In the upstream kernel which contained this patch, I did two tests: > > 1) use the makedumpfile as core_collector in /etc/kdump.conf, then > trigger the process of kdump by echo 1 >/proc/sysrq-trigger, the > makedumpfile works well and I can get the vmcore file. > > ..It is OK > > 2) use cp as core_collector, do the same operation to get the vmcore file. > then use makedumpfile to do like above: > > [douly@localhost code]$ ./makedumpfile -d 31 --message-level 31 -x > vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ Oh, then please ignore my previous comment. Adding '-D' can give more debugging message. > > ..It causes makedumpfile failed. > > > Thanks, > dou. > > > -Mike > > > > > > > >
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
Hi Kirill,Mike At 02/07/2018 06:45 PM, Mike Galbraith wrote: On Wed, 2018-02-07 at 13:41 +0300, Kirill A. Shutemov wrote: On Wed, Feb 07, 2018 at 05:25:05PM +0800, Dou Liyang wrote: Hi All, I met the makedumpfile failed in the upstream kernel which contained this patch. Did I missed something else? None I'm aware of. Is there a reason to suspect that the issue is related to the bug this patch fixed? I did a contrastive test by my colleagues Indoh's suggestion. Revert your two commits: commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 Author: Kirill A. ShutemovDate: Fri Sep 29 17:08:16 2017 +0300 commit 629a359bdb0e0652a8227b4ff3125431995fec6e Author: Kirill A. Shutemov Date: Tue Nov 7 11:33:37 2017 +0300 ...and keep others unchanged, the makedumpfile works well. Still works fine for me with .today. Box is only 16GB desktop box though. Btw, In the upstream kernel which contained this patch, I did two tests: 1) use the makedumpfile as core_collector in /etc/kdump.conf, then trigger the process of kdump by echo 1 >/proc/sysrq-trigger, the makedumpfile works well and I can get the vmcore file. ..It is OK 2) use cp as core_collector, do the same operation to get the vmcore file. then use makedumpfile to do like above: [douly@localhost code]$ ./makedumpfile -d 31 --message-level 31 -x vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ ..It causes makedumpfile failed. Thanks, dou. -Mike
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
Hi Kirill,Mike At 02/07/2018 06:45 PM, Mike Galbraith wrote: On Wed, 2018-02-07 at 13:41 +0300, Kirill A. Shutemov wrote: On Wed, Feb 07, 2018 at 05:25:05PM +0800, Dou Liyang wrote: Hi All, I met the makedumpfile failed in the upstream kernel which contained this patch. Did I missed something else? None I'm aware of. Is there a reason to suspect that the issue is related to the bug this patch fixed? I did a contrastive test by my colleagues Indoh's suggestion. Revert your two commits: commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 Author: Kirill A. Shutemov Date: Fri Sep 29 17:08:16 2017 +0300 commit 629a359bdb0e0652a8227b4ff3125431995fec6e Author: Kirill A. Shutemov Date: Tue Nov 7 11:33:37 2017 +0300 ...and keep others unchanged, the makedumpfile works well. Still works fine for me with .today. Box is only 16GB desktop box though. Btw, In the upstream kernel which contained this patch, I did two tests: 1) use the makedumpfile as core_collector in /etc/kdump.conf, then trigger the process of kdump by echo 1 >/proc/sysrq-trigger, the makedumpfile works well and I can get the vmcore file. ..It is OK 2) use cp as core_collector, do the same operation to get the vmcore file. then use makedumpfile to do like above: [douly@localhost code]$ ./makedumpfile -d 31 --message-level 31 -x vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ ..It causes makedumpfile failed. Thanks, dou. -Mike
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On 02/07/18 at 05:25pm, Dou Liyang wrote: > Hi All, > > I met the makedumpfile failed in the upstream kernel which contained > this patch. Did I missed something else? readmem: Can't convert a virtual address(88007ffd7000) to physical Should not related to this patch. Otherwise your code can't get to that step. From message, 88007ffd7000 is the end of the last mem region, seems a code bug. You are testing 5-level on makedumpfile, right? The patches I posted to descrease the memmory cost on mem map allocation has code bug, Fengguang's test robot sent a mail to me, I have updated patches, try to write a good patch log. You might also need check the 5-level patches you posted to makedumpfile upstream. > > In fedora27 host: > > [douly@localhost code]$ ./makedumpfile -d 31 --message-level 31 -x > vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ > > sadump: does not have partition header > sadump: read dump device as unknown format > sadump: unknown format > LOAD (0) > phys_start : 100 > phys_end : 2a86000 > virt_start : 8100 > virt_end : 82a86000 > LOAD (1) > phys_start : 1000 > phys_end : 9fc00 > virt_start : 88001000 > virt_end : 8809fc00 > LOAD (2) > phys_start : 10 > phys_end : 1300 > virt_start : 8810 > virt_end : 88001300 > LOAD (3) > phys_start : 3300 > phys_end : 7ffd7000 > virt_start : 88003300 > virt_end : 88007ffd7000 > Linux kdump > page_size: 4096 > > max_mapnr: 7ffd7 > > Buffer size for the cyclic mode: 131061 > The kernel version is not supported. > The makedumpfile operation may be incomplete. > > num of NODEs : 1 > > > Memory type : SPARSEMEM_EX > > mem_map (0) > mem_map: 88007ff26000 > pfn_start : 0 > pfn_end: 8000 > mem_map (1) > mem_map: 0 > pfn_start : 8000 > pfn_end: 1 > mem_map (2) > mem_map: 0 > pfn_start : 1 > pfn_end: 18000 > mem_map (3) > mem_map: 0 > pfn_start : 18000 > pfn_end: 2 > mem_map (4) > mem_map: 0 > pfn_start : 2 > pfn_end: 28000 > mem_map (5) > mem_map: 0 > pfn_start : 28000 > pfn_end: 3 > mem_map (6) > mem_map: 0 > pfn_start : 3 > pfn_end: 38000 > mem_map (7) > mem_map: 0 > pfn_start : 38000 > pfn_end: 4 > mem_map (8) > mem_map: 0 > pfn_start : 4 > pfn_end: 48000 > mem_map (9) > mem_map: 0 > pfn_start : 48000 > pfn_end: 5 > mem_map (10) > mem_map: 0 > pfn_start : 5 > pfn_end: 58000 > mem_map (11) > mem_map: 0 > pfn_start : 58000 > pfn_end: 6 > mem_map (12) > mem_map: 0 > pfn_start : 6 > pfn_end: 68000 > mem_map (13) > mem_map: 0 > pfn_start : 68000 > pfn_end: 7 > mem_map (14) > mem_map: 0 > pfn_start : 7 > pfn_end: 78000 > mem_map (15) > mem_map: 0 > pfn_start : 78000 > pfn_end: 7ffd7 > mmap() is available on the kernel. > Checking for memory holes : [100.0 %] | STEP > [Checking for memory holes ] : 0.60 seconds > __vtop4_x86_64: Can't get a valid pte. > readmem: Can't convert a virtual address(88007ffd7000) to physical > address. > readmem: type_addr: 0, addr:88007ffd7000, size:32768 > __exclude_unnecessary_pages: Can't read the buffer of struct page. > create_2nd_bitmap: Can't exclude unnecessary pages. > Checking for memory holes : [100.0 %] \ STEP > [Checking for memory holes ] : 0.10 seconds > Checking for memory holes : [100.0 %] - STEP > [Checking for memory holes ] : 0.04 seconds > __vtop4_x86_64: Can't get a valid pte. > readmem: Can't convert a virtual address(88007ffd7000) to physical > address. > readmem: type_addr: 0, addr:88007ffd7000, size:32768 > __exclude_unnecessary_pages: Can't read the buffer of struct page. > create_2nd_bitmap: Can't exclude unnecessary pages. > > Thanks, > dou > At 01/09/2018 11:44 AM, Mike Galbraith wrote: > > On Tue, 2018-01-09 at 03:13 +0300, Kirill A. Shutemov wrote: > > > > > > Mike, could you test this? (On top of the rest of the fixes.) > > > > homer:..crash/2018-01-09-04:25 # ll > > total 1863604 > > -rw--- 1 root root 66255 Jan 9 04:25 dmesg.txt > > -rw-r--r-- 1 root root182 Jan 9 04:25 README.txt > > -rw-r--r-- 1 root root2818240 Jan 9 04:25 > > System.map-4.15.0.gb2cd1df-master > > -rw--- 1 root root 1832914928 Jan 9 04:25 vmcore > > -rw-r--r-- 1 root root 72514993 Jan 9 04:25 > > vmlinux-4.15.0.gb2cd1df-master.gz > > > > Yup, all better. > > > > > Sorry for the mess. > > > > (why, developers not installing shiny new bugs is a whole lot worse:) > > > > > From 100fd567754f1457be94732046aefca204c842d2 Mon Sep 17 00:00:00 2001 > > > From: "Kirill A. Shutemov"
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On 02/07/18 at 05:25pm, Dou Liyang wrote: > Hi All, > > I met the makedumpfile failed in the upstream kernel which contained > this patch. Did I missed something else? readmem: Can't convert a virtual address(88007ffd7000) to physical Should not related to this patch. Otherwise your code can't get to that step. From message, 88007ffd7000 is the end of the last mem region, seems a code bug. You are testing 5-level on makedumpfile, right? The patches I posted to descrease the memmory cost on mem map allocation has code bug, Fengguang's test robot sent a mail to me, I have updated patches, try to write a good patch log. You might also need check the 5-level patches you posted to makedumpfile upstream. > > In fedora27 host: > > [douly@localhost code]$ ./makedumpfile -d 31 --message-level 31 -x > vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ > > sadump: does not have partition header > sadump: read dump device as unknown format > sadump: unknown format > LOAD (0) > phys_start : 100 > phys_end : 2a86000 > virt_start : 8100 > virt_end : 82a86000 > LOAD (1) > phys_start : 1000 > phys_end : 9fc00 > virt_start : 88001000 > virt_end : 8809fc00 > LOAD (2) > phys_start : 10 > phys_end : 1300 > virt_start : 8810 > virt_end : 88001300 > LOAD (3) > phys_start : 3300 > phys_end : 7ffd7000 > virt_start : 88003300 > virt_end : 88007ffd7000 > Linux kdump > page_size: 4096 > > max_mapnr: 7ffd7 > > Buffer size for the cyclic mode: 131061 > The kernel version is not supported. > The makedumpfile operation may be incomplete. > > num of NODEs : 1 > > > Memory type : SPARSEMEM_EX > > mem_map (0) > mem_map: 88007ff26000 > pfn_start : 0 > pfn_end: 8000 > mem_map (1) > mem_map: 0 > pfn_start : 8000 > pfn_end: 1 > mem_map (2) > mem_map: 0 > pfn_start : 1 > pfn_end: 18000 > mem_map (3) > mem_map: 0 > pfn_start : 18000 > pfn_end: 2 > mem_map (4) > mem_map: 0 > pfn_start : 2 > pfn_end: 28000 > mem_map (5) > mem_map: 0 > pfn_start : 28000 > pfn_end: 3 > mem_map (6) > mem_map: 0 > pfn_start : 3 > pfn_end: 38000 > mem_map (7) > mem_map: 0 > pfn_start : 38000 > pfn_end: 4 > mem_map (8) > mem_map: 0 > pfn_start : 4 > pfn_end: 48000 > mem_map (9) > mem_map: 0 > pfn_start : 48000 > pfn_end: 5 > mem_map (10) > mem_map: 0 > pfn_start : 5 > pfn_end: 58000 > mem_map (11) > mem_map: 0 > pfn_start : 58000 > pfn_end: 6 > mem_map (12) > mem_map: 0 > pfn_start : 6 > pfn_end: 68000 > mem_map (13) > mem_map: 0 > pfn_start : 68000 > pfn_end: 7 > mem_map (14) > mem_map: 0 > pfn_start : 7 > pfn_end: 78000 > mem_map (15) > mem_map: 0 > pfn_start : 78000 > pfn_end: 7ffd7 > mmap() is available on the kernel. > Checking for memory holes : [100.0 %] | STEP > [Checking for memory holes ] : 0.60 seconds > __vtop4_x86_64: Can't get a valid pte. > readmem: Can't convert a virtual address(88007ffd7000) to physical > address. > readmem: type_addr: 0, addr:88007ffd7000, size:32768 > __exclude_unnecessary_pages: Can't read the buffer of struct page. > create_2nd_bitmap: Can't exclude unnecessary pages. > Checking for memory holes : [100.0 %] \ STEP > [Checking for memory holes ] : 0.10 seconds > Checking for memory holes : [100.0 %] - STEP > [Checking for memory holes ] : 0.04 seconds > __vtop4_x86_64: Can't get a valid pte. > readmem: Can't convert a virtual address(88007ffd7000) to physical > address. > readmem: type_addr: 0, addr:88007ffd7000, size:32768 > __exclude_unnecessary_pages: Can't read the buffer of struct page. > create_2nd_bitmap: Can't exclude unnecessary pages. > > Thanks, > dou > At 01/09/2018 11:44 AM, Mike Galbraith wrote: > > On Tue, 2018-01-09 at 03:13 +0300, Kirill A. Shutemov wrote: > > > > > > Mike, could you test this? (On top of the rest of the fixes.) > > > > homer:..crash/2018-01-09-04:25 # ll > > total 1863604 > > -rw--- 1 root root 66255 Jan 9 04:25 dmesg.txt > > -rw-r--r-- 1 root root182 Jan 9 04:25 README.txt > > -rw-r--r-- 1 root root2818240 Jan 9 04:25 > > System.map-4.15.0.gb2cd1df-master > > -rw--- 1 root root 1832914928 Jan 9 04:25 vmcore > > -rw-r--r-- 1 root root 72514993 Jan 9 04:25 > > vmlinux-4.15.0.gb2cd1df-master.gz > > > > Yup, all better. > > > > > Sorry for the mess. > > > > (why, developers not installing shiny new bugs is a whole lot worse:) > > > > > From 100fd567754f1457be94732046aefca204c842d2 Mon Sep 17 00:00:00 2001 > > > From: "Kirill A. Shutemov" > > > Date: Tue, 9 Jan 2018
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Wed, 2018-02-07 at 13:41 +0300, Kirill A. Shutemov wrote: > On Wed, Feb 07, 2018 at 05:25:05PM +0800, Dou Liyang wrote: > > Hi All, > > > > I met the makedumpfile failed in the upstream kernel which contained > > this patch. Did I missed something else? > > None I'm aware of. > > Is there a reason to suspect that the issue is related to the bug this patch > fixed? Still works fine for me with .today. Box is only 16GB desktop box though. -Mike
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Wed, 2018-02-07 at 13:41 +0300, Kirill A. Shutemov wrote: > On Wed, Feb 07, 2018 at 05:25:05PM +0800, Dou Liyang wrote: > > Hi All, > > > > I met the makedumpfile failed in the upstream kernel which contained > > this patch. Did I missed something else? > > None I'm aware of. > > Is there a reason to suspect that the issue is related to the bug this patch > fixed? Still works fine for me with .today. Box is only 16GB desktop box though. -Mike
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Wed, Feb 07, 2018 at 05:25:05PM +0800, Dou Liyang wrote: > Hi All, > > I met the makedumpfile failed in the upstream kernel which contained > this patch. Did I missed something else? None I'm aware of. Is there a reason to suspect that the issue is related to the bug this patch fixed? -- Kirill A. Shutemov
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Wed, Feb 07, 2018 at 05:25:05PM +0800, Dou Liyang wrote: > Hi All, > > I met the makedumpfile failed in the upstream kernel which contained > this patch. Did I missed something else? None I'm aware of. Is there a reason to suspect that the issue is related to the bug this patch fixed? -- Kirill A. Shutemov
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
Hi All, I met the makedumpfile failed in the upstream kernel which contained this patch. Did I missed something else? In fedora27 host: [douly@localhost code]$ ./makedumpfile -d 31 --message-level 31 -x vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ sadump: does not have partition header sadump: read dump device as unknown format sadump: unknown format LOAD (0) phys_start : 100 phys_end : 2a86000 virt_start : 8100 virt_end : 82a86000 LOAD (1) phys_start : 1000 phys_end : 9fc00 virt_start : 88001000 virt_end : 8809fc00 LOAD (2) phys_start : 10 phys_end : 1300 virt_start : 8810 virt_end : 88001300 LOAD (3) phys_start : 3300 phys_end : 7ffd7000 virt_start : 88003300 virt_end : 88007ffd7000 Linux kdump page_size: 4096 max_mapnr: 7ffd7 Buffer size for the cyclic mode: 131061 The kernel version is not supported. The makedumpfile operation may be incomplete. num of NODEs : 1 Memory type : SPARSEMEM_EX mem_map (0) mem_map: 88007ff26000 pfn_start : 0 pfn_end: 8000 mem_map (1) mem_map: 0 pfn_start : 8000 pfn_end: 1 mem_map (2) mem_map: 0 pfn_start : 1 pfn_end: 18000 mem_map (3) mem_map: 0 pfn_start : 18000 pfn_end: 2 mem_map (4) mem_map: 0 pfn_start : 2 pfn_end: 28000 mem_map (5) mem_map: 0 pfn_start : 28000 pfn_end: 3 mem_map (6) mem_map: 0 pfn_start : 3 pfn_end: 38000 mem_map (7) mem_map: 0 pfn_start : 38000 pfn_end: 4 mem_map (8) mem_map: 0 pfn_start : 4 pfn_end: 48000 mem_map (9) mem_map: 0 pfn_start : 48000 pfn_end: 5 mem_map (10) mem_map: 0 pfn_start : 5 pfn_end: 58000 mem_map (11) mem_map: 0 pfn_start : 58000 pfn_end: 6 mem_map (12) mem_map: 0 pfn_start : 6 pfn_end: 68000 mem_map (13) mem_map: 0 pfn_start : 68000 pfn_end: 7 mem_map (14) mem_map: 0 pfn_start : 7 pfn_end: 78000 mem_map (15) mem_map: 0 pfn_start : 78000 pfn_end: 7ffd7 mmap() is available on the kernel. Checking for memory holes : [100.0 %] | STEP [Checking for memory holes ] : 0.60 seconds __vtop4_x86_64: Can't get a valid pte. readmem: Can't convert a virtual address(88007ffd7000) to physical address. readmem: type_addr: 0, addr:88007ffd7000, size:32768 __exclude_unnecessary_pages: Can't read the buffer of struct page. create_2nd_bitmap: Can't exclude unnecessary pages. Checking for memory holes : [100.0 %] \ STEP [Checking for memory holes ] : 0.10 seconds Checking for memory holes : [100.0 %] - STEP [Checking for memory holes ] : 0.04 seconds __vtop4_x86_64: Can't get a valid pte. readmem: Can't convert a virtual address(88007ffd7000) to physical address. readmem: type_addr: 0, addr:88007ffd7000, size:32768 __exclude_unnecessary_pages: Can't read the buffer of struct page. create_2nd_bitmap: Can't exclude unnecessary pages. Thanks, dou At 01/09/2018 11:44 AM, Mike Galbraith wrote: On Tue, 2018-01-09 at 03:13 +0300, Kirill A. Shutemov wrote: Mike, could you test this? (On top of the rest of the fixes.) homer:..crash/2018-01-09-04:25 # ll total 1863604 -rw--- 1 root root 66255 Jan 9 04:25 dmesg.txt -rw-r--r-- 1 root root182 Jan 9 04:25 README.txt -rw-r--r-- 1 root root2818240 Jan 9 04:25 System.map-4.15.0.gb2cd1df-master -rw--- 1 root root 1832914928 Jan 9 04:25 vmcore -rw-r--r-- 1 root root 72514993 Jan 9 04:25 vmlinux-4.15.0.gb2cd1df-master.gz Yup, all better. Sorry for the mess. (why, developers not installing shiny new bugs is a whole lot worse:) From 100fd567754f1457be94732046aefca204c842d2 Mon Sep 17 00:00:00 2001 From: "Kirill A. Shutemov"Date: Tue, 9 Jan 2018 02:55:47 +0300 Subject: [PATCH] kdump: Write a correct address of mem_section into vmcoreinfo Depending on configuration mem_section can now be an array or a pointer to an array allocated dynamically. In most cases, we can continue to refer to it as 'mem_section' regardless of what it is. But there's one exception: '_section' means "address of the array" if mem_section is an array, but if mem_section is a pointer, it would mean "address of the pointer". We've stepped onto this in kdump code. VMCOREINFO_SYMBOL(mem_section) writes down address of pointer into vmcoreinfo, not array as we wanted. Let's introduce VMCOREINFO_ARRAY() that would handle the situation correctly for both cases. Signed-off-by: Kirill A. Shutemov Fixes: 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y") --- include/linux/crash_core.h | 2 ++
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
Hi All, I met the makedumpfile failed in the upstream kernel which contained this patch. Did I missed something else? In fedora27 host: [douly@localhost code]$ ./makedumpfile -d 31 --message-level 31 -x vmlinux_4.15+ vmcore_4.15+_from_cp_command vmcore_4.15+ sadump: does not have partition header sadump: read dump device as unknown format sadump: unknown format LOAD (0) phys_start : 100 phys_end : 2a86000 virt_start : 8100 virt_end : 82a86000 LOAD (1) phys_start : 1000 phys_end : 9fc00 virt_start : 88001000 virt_end : 8809fc00 LOAD (2) phys_start : 10 phys_end : 1300 virt_start : 8810 virt_end : 88001300 LOAD (3) phys_start : 3300 phys_end : 7ffd7000 virt_start : 88003300 virt_end : 88007ffd7000 Linux kdump page_size: 4096 max_mapnr: 7ffd7 Buffer size for the cyclic mode: 131061 The kernel version is not supported. The makedumpfile operation may be incomplete. num of NODEs : 1 Memory type : SPARSEMEM_EX mem_map (0) mem_map: 88007ff26000 pfn_start : 0 pfn_end: 8000 mem_map (1) mem_map: 0 pfn_start : 8000 pfn_end: 1 mem_map (2) mem_map: 0 pfn_start : 1 pfn_end: 18000 mem_map (3) mem_map: 0 pfn_start : 18000 pfn_end: 2 mem_map (4) mem_map: 0 pfn_start : 2 pfn_end: 28000 mem_map (5) mem_map: 0 pfn_start : 28000 pfn_end: 3 mem_map (6) mem_map: 0 pfn_start : 3 pfn_end: 38000 mem_map (7) mem_map: 0 pfn_start : 38000 pfn_end: 4 mem_map (8) mem_map: 0 pfn_start : 4 pfn_end: 48000 mem_map (9) mem_map: 0 pfn_start : 48000 pfn_end: 5 mem_map (10) mem_map: 0 pfn_start : 5 pfn_end: 58000 mem_map (11) mem_map: 0 pfn_start : 58000 pfn_end: 6 mem_map (12) mem_map: 0 pfn_start : 6 pfn_end: 68000 mem_map (13) mem_map: 0 pfn_start : 68000 pfn_end: 7 mem_map (14) mem_map: 0 pfn_start : 7 pfn_end: 78000 mem_map (15) mem_map: 0 pfn_start : 78000 pfn_end: 7ffd7 mmap() is available on the kernel. Checking for memory holes : [100.0 %] | STEP [Checking for memory holes ] : 0.60 seconds __vtop4_x86_64: Can't get a valid pte. readmem: Can't convert a virtual address(88007ffd7000) to physical address. readmem: type_addr: 0, addr:88007ffd7000, size:32768 __exclude_unnecessary_pages: Can't read the buffer of struct page. create_2nd_bitmap: Can't exclude unnecessary pages. Checking for memory holes : [100.0 %] \ STEP [Checking for memory holes ] : 0.10 seconds Checking for memory holes : [100.0 %] - STEP [Checking for memory holes ] : 0.04 seconds __vtop4_x86_64: Can't get a valid pte. readmem: Can't convert a virtual address(88007ffd7000) to physical address. readmem: type_addr: 0, addr:88007ffd7000, size:32768 __exclude_unnecessary_pages: Can't read the buffer of struct page. create_2nd_bitmap: Can't exclude unnecessary pages. Thanks, dou At 01/09/2018 11:44 AM, Mike Galbraith wrote: On Tue, 2018-01-09 at 03:13 +0300, Kirill A. Shutemov wrote: Mike, could you test this? (On top of the rest of the fixes.) homer:..crash/2018-01-09-04:25 # ll total 1863604 -rw--- 1 root root 66255 Jan 9 04:25 dmesg.txt -rw-r--r-- 1 root root182 Jan 9 04:25 README.txt -rw-r--r-- 1 root root2818240 Jan 9 04:25 System.map-4.15.0.gb2cd1df-master -rw--- 1 root root 1832914928 Jan 9 04:25 vmcore -rw-r--r-- 1 root root 72514993 Jan 9 04:25 vmlinux-4.15.0.gb2cd1df-master.gz Yup, all better. Sorry for the mess. (why, developers not installing shiny new bugs is a whole lot worse:) From 100fd567754f1457be94732046aefca204c842d2 Mon Sep 17 00:00:00 2001 From: "Kirill A. Shutemov" Date: Tue, 9 Jan 2018 02:55:47 +0300 Subject: [PATCH] kdump: Write a correct address of mem_section into vmcoreinfo Depending on configuration mem_section can now be an array or a pointer to an array allocated dynamically. In most cases, we can continue to refer to it as 'mem_section' regardless of what it is. But there's one exception: '_section' means "address of the array" if mem_section is an array, but if mem_section is a pointer, it would mean "address of the pointer". We've stepped onto this in kdump code. VMCOREINFO_SYMBOL(mem_section) writes down address of pointer into vmcoreinfo, not array as we wanted. Let's introduce VMCOREINFO_ARRAY() that would handle the situation correctly for both cases. Signed-off-by: Kirill A. Shutemov Fixes: 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y") --- include/linux/crash_core.h | 2 ++ kernel/crash_core.c| 2 +- 2 files changed, 3 insertions(+), 1
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On 01/25/18 at 06:50pm, Kirill A. Shutemov wrote: > On Wed, Jan 17, 2018 at 01:24:54PM +0800, Baoquan He wrote: > > Hi Kirill, > > > > I setup qemu 2.9.0 to test 5-level on kexec/kdump support. While both > > kexec and kdump reset to BIOS immediately after triggering. I saw your > > patch adding 5-level paging support for kexec. Wonder if your test > > succeeded to jump into kexec/kdump kernel, and what else I need to > > make it. By the way, I just tested the latest upstream kernel. > > > > commit 7f6890418 x86/kexec: Add 5-level paging support > > > > [ ~]$ qemu-system-x86_64 --version > > QEMU emulator version 2.9.0(qemu-2.9.0-1.fc26.1) > > Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers > > Sorry for delay. > > I didn't tested it in 5-level paging mode :-/ > > The patch below helps in my case. Could you test it? Thanks, Kirill. Seems it doesn't work. I have some confusion about the process, will send you a private mail. Thanks Baoquan > > diff --git a/arch/x86/kernel/relocate_kernel_64.S > b/arch/x86/kernel/relocate_kernel_64.S > index 307d3bac5f04..65a98cf2307d 100644 > --- a/arch/x86/kernel/relocate_kernel_64.S > +++ b/arch/x86/kernel/relocate_kernel_64.S > @@ -126,8 +126,12 @@ identity_mapped: > /* > * Set cr4 to a known state: > * - physical address extension enabled > +* - 5-level paging, if enabled > */ > movl$X86_CR4_PAE, %eax > +#ifdef CONFIG_X86_5LEVEL > + orl $X86_CR4_LA57, %eax > +#endif > movq%rax, %cr4 > > jmp 1f > -- > Kirill A. Shutemov
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On 01/25/18 at 06:50pm, Kirill A. Shutemov wrote: > On Wed, Jan 17, 2018 at 01:24:54PM +0800, Baoquan He wrote: > > Hi Kirill, > > > > I setup qemu 2.9.0 to test 5-level on kexec/kdump support. While both > > kexec and kdump reset to BIOS immediately after triggering. I saw your > > patch adding 5-level paging support for kexec. Wonder if your test > > succeeded to jump into kexec/kdump kernel, and what else I need to > > make it. By the way, I just tested the latest upstream kernel. > > > > commit 7f6890418 x86/kexec: Add 5-level paging support > > > > [ ~]$ qemu-system-x86_64 --version > > QEMU emulator version 2.9.0(qemu-2.9.0-1.fc26.1) > > Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers > > Sorry for delay. > > I didn't tested it in 5-level paging mode :-/ > > The patch below helps in my case. Could you test it? Thanks, Kirill. Seems it doesn't work. I have some confusion about the process, will send you a private mail. Thanks Baoquan > > diff --git a/arch/x86/kernel/relocate_kernel_64.S > b/arch/x86/kernel/relocate_kernel_64.S > index 307d3bac5f04..65a98cf2307d 100644 > --- a/arch/x86/kernel/relocate_kernel_64.S > +++ b/arch/x86/kernel/relocate_kernel_64.S > @@ -126,8 +126,12 @@ identity_mapped: > /* > * Set cr4 to a known state: > * - physical address extension enabled > +* - 5-level paging, if enabled > */ > movl$X86_CR4_PAE, %eax > +#ifdef CONFIG_X86_5LEVEL > + orl $X86_CR4_LA57, %eax > +#endif > movq%rax, %cr4 > > jmp 1f > -- > Kirill A. Shutemov
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Wed, Jan 17, 2018 at 01:24:54PM +0800, Baoquan He wrote: > Hi Kirill, > > I setup qemu 2.9.0 to test 5-level on kexec/kdump support. While both > kexec and kdump reset to BIOS immediately after triggering. I saw your > patch adding 5-level paging support for kexec. Wonder if your test > succeeded to jump into kexec/kdump kernel, and what else I need to > make it. By the way, I just tested the latest upstream kernel. > > commit 7f6890418 x86/kexec: Add 5-level paging support > > [ ~]$ qemu-system-x86_64 --version > QEMU emulator version 2.9.0(qemu-2.9.0-1.fc26.1) > Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers Sorry for delay. I didn't tested it in 5-level paging mode :-/ The patch below helps in my case. Could you test it? diff --git a/arch/x86/kernel/relocate_kernel_64.S b/arch/x86/kernel/relocate_kernel_64.S index 307d3bac5f04..65a98cf2307d 100644 --- a/arch/x86/kernel/relocate_kernel_64.S +++ b/arch/x86/kernel/relocate_kernel_64.S @@ -126,8 +126,12 @@ identity_mapped: /* * Set cr4 to a known state: * - physical address extension enabled +* - 5-level paging, if enabled */ movl$X86_CR4_PAE, %eax +#ifdef CONFIG_X86_5LEVEL + orl $X86_CR4_LA57, %eax +#endif movq%rax, %cr4 jmp 1f -- Kirill A. Shutemov
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Wed, Jan 17, 2018 at 01:24:54PM +0800, Baoquan He wrote: > Hi Kirill, > > I setup qemu 2.9.0 to test 5-level on kexec/kdump support. While both > kexec and kdump reset to BIOS immediately after triggering. I saw your > patch adding 5-level paging support for kexec. Wonder if your test > succeeded to jump into kexec/kdump kernel, and what else I need to > make it. By the way, I just tested the latest upstream kernel. > > commit 7f6890418 x86/kexec: Add 5-level paging support > > [ ~]$ qemu-system-x86_64 --version > QEMU emulator version 2.9.0(qemu-2.9.0-1.fc26.1) > Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers Sorry for delay. I didn't tested it in 5-level paging mode :-/ The patch below helps in my case. Could you test it? diff --git a/arch/x86/kernel/relocate_kernel_64.S b/arch/x86/kernel/relocate_kernel_64.S index 307d3bac5f04..65a98cf2307d 100644 --- a/arch/x86/kernel/relocate_kernel_64.S +++ b/arch/x86/kernel/relocate_kernel_64.S @@ -126,8 +126,12 @@ identity_mapped: /* * Set cr4 to a known state: * - physical address extension enabled +* - 5-level paging, if enabled */ movl$X86_CR4_PAE, %eax +#ifdef CONFIG_X86_5LEVEL + orl $X86_CR4_LA57, %eax +#endif movq%rax, %cr4 jmp 1f -- Kirill A. Shutemov
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
Hi Kirill, I setup qemu 2.9.0 to test 5-level on kexec/kdump support. While both kexec and kdump reset to BIOS immediately after triggering. I saw your patch adding 5-level paging support for kexec. Wonder if your test succeeded to jump into kexec/kdump kernel, and what else I need to make it. By the way, I just tested the latest upstream kernel. commit 7f6890418 x86/kexec: Add 5-level paging support [ ~]$ qemu-system-x86_64 --version QEMU emulator version 2.9.0(qemu-2.9.0-1.fc26.1) Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers Thanks Baoquan On 01/09/18 at 03:13am, Kirill A. Shutemov wrote: > On Mon, Jan 08, 2018 at 08:46:53PM +0300, Kirill A. Shutemov wrote: > > On Mon, Jan 08, 2018 at 04:04:44PM +, Ingo Molnar wrote: > > > > > > hi Kirill, > > > > > > As Mike reported it below, your 5-level paging related upstream commit > > > 83e3c48729d9 and all its followup fixes: > > > > > > 83e3c48729d9: mm/sparsemem: Allocate mem_section at runtime for > > > CONFIG_SPARSEMEM_EXTREME=y > > > 629a359bdb0e: mm/sparsemem: Fix ARM64 boot crash when > > > CONFIG_SPARSEMEM_EXTREME=y > > > d09cfbbfa0f7: mm/sparse.c: wrong allocation for mem_section > > > > > > ... still breaks kexec - and that now regresses -stable as well. > > > > > > Given that 5-level paging now syntactically depends on having this > > > commit, if we > > > fully revert this then we'll have to disable 5-level paging as well. > > This *should* help. > > Mike, could you test this? (On top of the rest of the fixes.) > > Sorry for the mess. > > From 100fd567754f1457be94732046aefca204c842d2 Mon Sep 17 00:00:00 2001 > From: "Kirill A. Shutemov"> Date: Tue, 9 Jan 2018 02:55:47 +0300 > Subject: [PATCH] kdump: Write a correct address of mem_section into vmcoreinfo > > Depending on configuration mem_section can now be an array or a pointer > to an array allocated dynamically. In most cases, we can continue to refer > to it as 'mem_section' regardless of what it is. > > But there's one exception: '_section' means "address of the array" if > mem_section is an array, but if mem_section is a pointer, it would mean > "address of the pointer". > > We've stepped onto this in kdump code. VMCOREINFO_SYMBOL(mem_section) > writes down address of pointer into vmcoreinfo, not array as we wanted. > > Let's introduce VMCOREINFO_ARRAY() that would handle the situation > correctly for both cases. > > Signed-off-by: Kirill A. Shutemov > Fixes: 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for > CONFIG_SPARSEMEM_EXTREME=y") > --- > include/linux/crash_core.h | 2 ++ > kernel/crash_core.c| 2 +- > 2 files changed, 3 insertions(+), 1 deletion(-) > > diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h > index 06097ef30449..83ae04950269 100644 > --- a/include/linux/crash_core.h > +++ b/include/linux/crash_core.h > @@ -42,6 +42,8 @@ phys_addr_t paddr_vmcoreinfo_note(void); > vmcoreinfo_append_str("PAGESIZE=%ld\n", value) > #define VMCOREINFO_SYMBOL(name) \ > vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)) > +#define VMCOREINFO_ARRAY(name) \ > + vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)name) > #define VMCOREINFO_SIZE(name) \ > vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \ > (unsigned long)sizeof(name)) > diff --git a/kernel/crash_core.c b/kernel/crash_core.c > index b3663896278e..d4122a837477 100644 > --- a/kernel/crash_core.c > +++ b/kernel/crash_core.c > @@ -410,7 +410,7 @@ static int __init crash_save_vmcoreinfo_init(void) > VMCOREINFO_SYMBOL(contig_page_data); > #endif > #ifdef CONFIG_SPARSEMEM > - VMCOREINFO_SYMBOL(mem_section); > + VMCOREINFO_ARRAY(mem_section); > VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS); > VMCOREINFO_STRUCT_SIZE(mem_section); > VMCOREINFO_OFFSET(mem_section, section_mem_map); > -- > Kirill A. Shutemov > > ___ > kexec mailing list > ke...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
Hi Kirill, I setup qemu 2.9.0 to test 5-level on kexec/kdump support. While both kexec and kdump reset to BIOS immediately after triggering. I saw your patch adding 5-level paging support for kexec. Wonder if your test succeeded to jump into kexec/kdump kernel, and what else I need to make it. By the way, I just tested the latest upstream kernel. commit 7f6890418 x86/kexec: Add 5-level paging support [ ~]$ qemu-system-x86_64 --version QEMU emulator version 2.9.0(qemu-2.9.0-1.fc26.1) Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers Thanks Baoquan On 01/09/18 at 03:13am, Kirill A. Shutemov wrote: > On Mon, Jan 08, 2018 at 08:46:53PM +0300, Kirill A. Shutemov wrote: > > On Mon, Jan 08, 2018 at 04:04:44PM +, Ingo Molnar wrote: > > > > > > hi Kirill, > > > > > > As Mike reported it below, your 5-level paging related upstream commit > > > 83e3c48729d9 and all its followup fixes: > > > > > > 83e3c48729d9: mm/sparsemem: Allocate mem_section at runtime for > > > CONFIG_SPARSEMEM_EXTREME=y > > > 629a359bdb0e: mm/sparsemem: Fix ARM64 boot crash when > > > CONFIG_SPARSEMEM_EXTREME=y > > > d09cfbbfa0f7: mm/sparse.c: wrong allocation for mem_section > > > > > > ... still breaks kexec - and that now regresses -stable as well. > > > > > > Given that 5-level paging now syntactically depends on having this > > > commit, if we > > > fully revert this then we'll have to disable 5-level paging as well. > > This *should* help. > > Mike, could you test this? (On top of the rest of the fixes.) > > Sorry for the mess. > > From 100fd567754f1457be94732046aefca204c842d2 Mon Sep 17 00:00:00 2001 > From: "Kirill A. Shutemov" > Date: Tue, 9 Jan 2018 02:55:47 +0300 > Subject: [PATCH] kdump: Write a correct address of mem_section into vmcoreinfo > > Depending on configuration mem_section can now be an array or a pointer > to an array allocated dynamically. In most cases, we can continue to refer > to it as 'mem_section' regardless of what it is. > > But there's one exception: '_section' means "address of the array" if > mem_section is an array, but if mem_section is a pointer, it would mean > "address of the pointer". > > We've stepped onto this in kdump code. VMCOREINFO_SYMBOL(mem_section) > writes down address of pointer into vmcoreinfo, not array as we wanted. > > Let's introduce VMCOREINFO_ARRAY() that would handle the situation > correctly for both cases. > > Signed-off-by: Kirill A. Shutemov > Fixes: 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for > CONFIG_SPARSEMEM_EXTREME=y") > --- > include/linux/crash_core.h | 2 ++ > kernel/crash_core.c| 2 +- > 2 files changed, 3 insertions(+), 1 deletion(-) > > diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h > index 06097ef30449..83ae04950269 100644 > --- a/include/linux/crash_core.h > +++ b/include/linux/crash_core.h > @@ -42,6 +42,8 @@ phys_addr_t paddr_vmcoreinfo_note(void); > vmcoreinfo_append_str("PAGESIZE=%ld\n", value) > #define VMCOREINFO_SYMBOL(name) \ > vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)) > +#define VMCOREINFO_ARRAY(name) \ > + vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)name) > #define VMCOREINFO_SIZE(name) \ > vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \ > (unsigned long)sizeof(name)) > diff --git a/kernel/crash_core.c b/kernel/crash_core.c > index b3663896278e..d4122a837477 100644 > --- a/kernel/crash_core.c > +++ b/kernel/crash_core.c > @@ -410,7 +410,7 @@ static int __init crash_save_vmcoreinfo_init(void) > VMCOREINFO_SYMBOL(contig_page_data); > #endif > #ifdef CONFIG_SPARSEMEM > - VMCOREINFO_SYMBOL(mem_section); > + VMCOREINFO_ARRAY(mem_section); > VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS); > VMCOREINFO_STRUCT_SIZE(mem_section); > VMCOREINFO_OFFSET(mem_section, section_mem_map); > -- > Kirill A. Shutemov > > ___ > kexec mailing list > ke...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec
RE: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
>Hm, this fix means that the vmlinux symbol table and vmcoreinfo have >different values for mem_section. That seems... odd. I had to patch >makedumpfile to fix the case of an explicit vmlinux being passed on the >command line (which I realized I don't need to do, but it should still >work): Looks good to me, I'll merge this into makedumpfile-1.6.4. Thanks, Atsushi Kumagai >From 542a11a8f28b0f0a989abc3adff89da22f44c719 Mon Sep 17 00:00:00 2001 >Message-Id: ><542a11a8f28b0f0a989abc3adff89da22f44c719.1515995400.git.osan...@fb.com> >From: Omar Sandoval>Date: Sun, 14 Jan 2018 17:10:30 -0800 >Subject: [PATCH] Fix SPARSEMEM_EXTREME support on Linux v4.15 when passing > vmlinux > >Since kernel commit 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at >runtime for CONFIG_SPARSEMEM_EXTREME=y"), mem_section is a dynamically >allocated array of pointers to mem_section instead of a static one >(i.e., struct mem_section ** instead of struct mem_section * []). This >adds an extra layer of indirection that breaks makedumpfile, which will >end up with a bunch of bogus mem_maps. > >Since kernel commit a0b1280368d1 ("kdump: write correct address of >mem_section into vmcoreinfo"), the mem_section symbol in vmcoreinfo >contains the address of the actual struct mem_section * array instead of >the address of the pointer in .bss, which gets rid of the extra >indirection. However, makedumpfile still uses the debugging symbol from >the vmlinux image. Fix this by allowing symbols from the vmcore to >override symbols from the vmlinux image. As the comment in initial() >says, "vmcoreinfo in /proc/vmcore is more reliable than -x/-i option". > >Signed-off-by: Omar Sandoval >--- > makedumpfile.h | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > >diff --git a/makedumpfile.h b/makedumpfile.h >index 57cf4d9..d68c798 100644 >--- a/makedumpfile.h >+++ b/makedumpfile.h >@@ -274,8 +274,10 @@ do { \ > } while (0) > #define READ_SYMBOL(str_symbol, symbol) \ > do { \ >- if (SYMBOL(symbol) == NOT_FOUND_SYMBOL) { \ >- SYMBOL(symbol) = >read_vmcoreinfo_symbol(STR_SYMBOL(str_symbol)); \ >+ unsigned long _tmp_symbol; \ >+ _tmp_symbol = read_vmcoreinfo_symbol(STR_SYMBOL(str_symbol)); \ >+ if (_tmp_symbol != NOT_FOUND_SYMBOL) { \ >+ SYMBOL(symbol) = _tmp_symbol; \ > if (SYMBOL(symbol) == INVALID_SYMBOL_DATA) \ > return FALSE; \ > } \ >-- >2.9.5 > > >___ >kexec mailing list >ke...@lists.infradead.org >http://lists.infradead.org/mailman/listinfo/kexec
RE: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
>Hm, this fix means that the vmlinux symbol table and vmcoreinfo have >different values for mem_section. That seems... odd. I had to patch >makedumpfile to fix the case of an explicit vmlinux being passed on the >command line (which I realized I don't need to do, but it should still >work): Looks good to me, I'll merge this into makedumpfile-1.6.4. Thanks, Atsushi Kumagai >From 542a11a8f28b0f0a989abc3adff89da22f44c719 Mon Sep 17 00:00:00 2001 >Message-Id: ><542a11a8f28b0f0a989abc3adff89da22f44c719.1515995400.git.osan...@fb.com> >From: Omar Sandoval >Date: Sun, 14 Jan 2018 17:10:30 -0800 >Subject: [PATCH] Fix SPARSEMEM_EXTREME support on Linux v4.15 when passing > vmlinux > >Since kernel commit 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at >runtime for CONFIG_SPARSEMEM_EXTREME=y"), mem_section is a dynamically >allocated array of pointers to mem_section instead of a static one >(i.e., struct mem_section ** instead of struct mem_section * []). This >adds an extra layer of indirection that breaks makedumpfile, which will >end up with a bunch of bogus mem_maps. > >Since kernel commit a0b1280368d1 ("kdump: write correct address of >mem_section into vmcoreinfo"), the mem_section symbol in vmcoreinfo >contains the address of the actual struct mem_section * array instead of >the address of the pointer in .bss, which gets rid of the extra >indirection. However, makedumpfile still uses the debugging symbol from >the vmlinux image. Fix this by allowing symbols from the vmcore to >override symbols from the vmlinux image. As the comment in initial() >says, "vmcoreinfo in /proc/vmcore is more reliable than -x/-i option". > >Signed-off-by: Omar Sandoval >--- > makedumpfile.h | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > >diff --git a/makedumpfile.h b/makedumpfile.h >index 57cf4d9..d68c798 100644 >--- a/makedumpfile.h >+++ b/makedumpfile.h >@@ -274,8 +274,10 @@ do { \ > } while (0) > #define READ_SYMBOL(str_symbol, symbol) \ > do { \ >- if (SYMBOL(symbol) == NOT_FOUND_SYMBOL) { \ >- SYMBOL(symbol) = >read_vmcoreinfo_symbol(STR_SYMBOL(str_symbol)); \ >+ unsigned long _tmp_symbol; \ >+ _tmp_symbol = read_vmcoreinfo_symbol(STR_SYMBOL(str_symbol)); \ >+ if (_tmp_symbol != NOT_FOUND_SYMBOL) { \ >+ SYMBOL(symbol) = _tmp_symbol; \ > if (SYMBOL(symbol) == INVALID_SYMBOL_DATA) \ > return FALSE; \ > } \ >-- >2.9.5 > > >___ >kexec mailing list >ke...@lists.infradead.org >http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Fri, Jan 12, 2018 at 08:55:49AM +0800, Dave Young wrote: > On 01/10/18 at 02:16pm, Kirill A. Shutemov wrote: > > On Wed, Jan 10, 2018 at 03:08:04AM +, Dave Young wrote: > > > On Tue, Jan 09, 2018 at 12:05:52PM +0300, Kirill A. Shutemov wrote: > > > > On Tue, Jan 09, 2018 at 03:24:40PM +0800, Dave Young wrote: > > > > > On 01/09/18 at 01:41pm, Baoquan He wrote: > > > > > > On 01/09/18 at 09:09am, Dave Young wrote: > > > > > > > > > > > > > As for the macro name, VMCOREINFO_SYMBOL_ARRAY sounds better. > > > > > > > > Yep, that's better. > > > > > > > > > > I still think using vmcoreinfo_append_str is better. Unless we > > > > > > replace > > > > > > all array variables with the newly added macro. > > > > > > > > > > > > vmcoreinfo_append_str("SYMBOL(mem_section)=%lx\n", > > > > > > (unsigned long)mem_section); > > > > > > > > > > I have no strong opinion, either change all array uses or just > > > > > introduce > > > > > the macro and start to use it from now on if we have similar array > > > > > symbols. > > > > > > > > Do you need some action on my side or will you folks take care about > > > > this? > > > > > > I think Baoquan was suggesting to update all array users in current > > > code, if you can check every VMCOREINFO_SYMBOL and update all the arrays > > > he will be happy. But if can not do it easily I'm fine with a > > > VMCOREINFO_SYMBOL_ARRAY changes only now, we kdump people can do it > > > later as well. > > > > It seems it's the only array we have there. swapper_pg_dir is a potential > > candidate, but it's 'unsigned long' on arm. > > > > Below it patch with corrected macro name. > > > > Please, consider applying. > > > > From 70f3a84b97f2de98d1364f7b10b7a42a1d8e9968 Mon Sep 17 00:00:00 2001 > > From: "Kirill A. Shutemov"> > Date: Tue, 9 Jan 2018 02:55:47 +0300 > > Subject: [PATCH] kdump: Write a correct address of mem_section into > > vmcoreinfo > > > > Depending on configuration mem_section can now be an array or a pointer > > to an array allocated dynamically. In most cases, we can continue to refer > > to it as 'mem_section' regardless of what it is. > > > > But there's one exception: '_section' means "address of the array" if > > mem_section is an array, but if mem_section is a pointer, it would mean > > "address of the pointer". > > > > We've stepped onto this in kdump code. VMCOREINFO_SYMBOL(mem_section) > > writes down address of pointer into vmcoreinfo, not array as we wanted. > > > > Let's introduce VMCOREINFO_SYMBOL_ARRAY() that would handle the > > situation correctly for both cases. > > > > Signed-off-by: Kirill A. Shutemov > > Fixes: 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for > > CONFIG_SPARSEMEM_EXTREME=y") > > --- > > include/linux/crash_core.h | 2 ++ > > kernel/crash_core.c| 2 +- > > 2 files changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h > > index 06097ef30449..b511f6d24b42 100644 > > --- a/include/linux/crash_core.h > > +++ b/include/linux/crash_core.h > > @@ -42,6 +42,8 @@ phys_addr_t paddr_vmcoreinfo_note(void); > > vmcoreinfo_append_str("PAGESIZE=%ld\n", value) > > #define VMCOREINFO_SYMBOL(name) \ > > vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)) > > +#define VMCOREINFO_SYMBOL_ARRAY(name) \ > > + vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)name) > > #define VMCOREINFO_SIZE(name) \ > > vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \ > > (unsigned long)sizeof(name)) > > diff --git a/kernel/crash_core.c b/kernel/crash_core.c > > index b3663896278e..4f63597c824d 100644 > > --- a/kernel/crash_core.c > > +++ b/kernel/crash_core.c > > @@ -410,7 +410,7 @@ static int __init crash_save_vmcoreinfo_init(void) > > VMCOREINFO_SYMBOL(contig_page_data); > > #endif > > #ifdef CONFIG_SPARSEMEM > > - VMCOREINFO_SYMBOL(mem_section); > > + VMCOREINFO_SYMBOL_ARRAY(mem_section); > > VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS); > > VMCOREINFO_STRUCT_SIZE(mem_section); > > VMCOREINFO_OFFSET(mem_section, section_mem_map); > > -- > > Kirill A. Shutemov > > > Acked-by: Dave Young > > If stable kernel took the mem section commits, then should also cc > stable. Andrew, can you help to make this in 4.15? > > Thanks > Dave Hm, this fix means that the vmlinux symbol table and vmcoreinfo have different values for mem_section. That seems... odd. I had to patch makedumpfile to fix the case of an explicit vmlinux being passed on the command line (which I realized I don't need to do, but it should still work): >From 542a11a8f28b0f0a989abc3adff89da22f44c719 Mon Sep 17 00:00:00 2001 Message-Id: <542a11a8f28b0f0a989abc3adff89da22f44c719.1515995400.git.osan...@fb.com> From: Omar Sandoval Date: Sun, 14 Jan 2018 17:10:30 -0800
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Fri, Jan 12, 2018 at 08:55:49AM +0800, Dave Young wrote: > On 01/10/18 at 02:16pm, Kirill A. Shutemov wrote: > > On Wed, Jan 10, 2018 at 03:08:04AM +, Dave Young wrote: > > > On Tue, Jan 09, 2018 at 12:05:52PM +0300, Kirill A. Shutemov wrote: > > > > On Tue, Jan 09, 2018 at 03:24:40PM +0800, Dave Young wrote: > > > > > On 01/09/18 at 01:41pm, Baoquan He wrote: > > > > > > On 01/09/18 at 09:09am, Dave Young wrote: > > > > > > > > > > > > > As for the macro name, VMCOREINFO_SYMBOL_ARRAY sounds better. > > > > > > > > Yep, that's better. > > > > > > > > > > I still think using vmcoreinfo_append_str is better. Unless we > > > > > > replace > > > > > > all array variables with the newly added macro. > > > > > > > > > > > > vmcoreinfo_append_str("SYMBOL(mem_section)=%lx\n", > > > > > > (unsigned long)mem_section); > > > > > > > > > > I have no strong opinion, either change all array uses or just > > > > > introduce > > > > > the macro and start to use it from now on if we have similar array > > > > > symbols. > > > > > > > > Do you need some action on my side or will you folks take care about > > > > this? > > > > > > I think Baoquan was suggesting to update all array users in current > > > code, if you can check every VMCOREINFO_SYMBOL and update all the arrays > > > he will be happy. But if can not do it easily I'm fine with a > > > VMCOREINFO_SYMBOL_ARRAY changes only now, we kdump people can do it > > > later as well. > > > > It seems it's the only array we have there. swapper_pg_dir is a potential > > candidate, but it's 'unsigned long' on arm. > > > > Below it patch with corrected macro name. > > > > Please, consider applying. > > > > From 70f3a84b97f2de98d1364f7b10b7a42a1d8e9968 Mon Sep 17 00:00:00 2001 > > From: "Kirill A. Shutemov" > > Date: Tue, 9 Jan 2018 02:55:47 +0300 > > Subject: [PATCH] kdump: Write a correct address of mem_section into > > vmcoreinfo > > > > Depending on configuration mem_section can now be an array or a pointer > > to an array allocated dynamically. In most cases, we can continue to refer > > to it as 'mem_section' regardless of what it is. > > > > But there's one exception: '_section' means "address of the array" if > > mem_section is an array, but if mem_section is a pointer, it would mean > > "address of the pointer". > > > > We've stepped onto this in kdump code. VMCOREINFO_SYMBOL(mem_section) > > writes down address of pointer into vmcoreinfo, not array as we wanted. > > > > Let's introduce VMCOREINFO_SYMBOL_ARRAY() that would handle the > > situation correctly for both cases. > > > > Signed-off-by: Kirill A. Shutemov > > Fixes: 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for > > CONFIG_SPARSEMEM_EXTREME=y") > > --- > > include/linux/crash_core.h | 2 ++ > > kernel/crash_core.c| 2 +- > > 2 files changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h > > index 06097ef30449..b511f6d24b42 100644 > > --- a/include/linux/crash_core.h > > +++ b/include/linux/crash_core.h > > @@ -42,6 +42,8 @@ phys_addr_t paddr_vmcoreinfo_note(void); > > vmcoreinfo_append_str("PAGESIZE=%ld\n", value) > > #define VMCOREINFO_SYMBOL(name) \ > > vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)) > > +#define VMCOREINFO_SYMBOL_ARRAY(name) \ > > + vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)name) > > #define VMCOREINFO_SIZE(name) \ > > vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \ > > (unsigned long)sizeof(name)) > > diff --git a/kernel/crash_core.c b/kernel/crash_core.c > > index b3663896278e..4f63597c824d 100644 > > --- a/kernel/crash_core.c > > +++ b/kernel/crash_core.c > > @@ -410,7 +410,7 @@ static int __init crash_save_vmcoreinfo_init(void) > > VMCOREINFO_SYMBOL(contig_page_data); > > #endif > > #ifdef CONFIG_SPARSEMEM > > - VMCOREINFO_SYMBOL(mem_section); > > + VMCOREINFO_SYMBOL_ARRAY(mem_section); > > VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS); > > VMCOREINFO_STRUCT_SIZE(mem_section); > > VMCOREINFO_OFFSET(mem_section, section_mem_map); > > -- > > Kirill A. Shutemov > > > Acked-by: Dave Young > > If stable kernel took the mem section commits, then should also cc > stable. Andrew, can you help to make this in 4.15? > > Thanks > Dave Hm, this fix means that the vmlinux symbol table and vmcoreinfo have different values for mem_section. That seems... odd. I had to patch makedumpfile to fix the case of an explicit vmlinux being passed on the command line (which I realized I don't need to do, but it should still work): >From 542a11a8f28b0f0a989abc3adff89da22f44c719 Mon Sep 17 00:00:00 2001 Message-Id: <542a11a8f28b0f0a989abc3adff89da22f44c719.1515995400.git.osan...@fb.com> From: Omar Sandoval Date: Sun, 14 Jan 2018 17:10:30 -0800 Subject: [PATCH] Fix SPARSEMEM_EXTREME support on Linux v4.15 when passing vmlinux Since kernel commit
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On 01/10/18 at 02:16pm, Kirill A. Shutemov wrote: > On Wed, Jan 10, 2018 at 03:08:04AM +, Dave Young wrote: > > On Tue, Jan 09, 2018 at 12:05:52PM +0300, Kirill A. Shutemov wrote: > > > On Tue, Jan 09, 2018 at 03:24:40PM +0800, Dave Young wrote: > > > > On 01/09/18 at 01:41pm, Baoquan He wrote: > > > > > On 01/09/18 at 09:09am, Dave Young wrote: > > > > > > > > > > > As for the macro name, VMCOREINFO_SYMBOL_ARRAY sounds better. > > > > > > Yep, that's better. > > > > > > > > I still think using vmcoreinfo_append_str is better. Unless we replace > > > > > all array variables with the newly added macro. > > > > > > > > > > vmcoreinfo_append_str("SYMBOL(mem_section)=%lx\n", > > > > > (unsigned long)mem_section); > > > > > > > > I have no strong opinion, either change all array uses or just introduce > > > > the macro and start to use it from now on if we have similar array > > > > symbols. > > > > > > Do you need some action on my side or will you folks take care about this? > > > > I think Baoquan was suggesting to update all array users in current > > code, if you can check every VMCOREINFO_SYMBOL and update all the arrays > > he will be happy. But if can not do it easily I'm fine with a > > VMCOREINFO_SYMBOL_ARRAY changes only now, we kdump people can do it > > later as well. > > It seems it's the only array we have there. swapper_pg_dir is a potential > candidate, but it's 'unsigned long' on arm. > > Below it patch with corrected macro name. > > Please, consider applying. > > From 70f3a84b97f2de98d1364f7b10b7a42a1d8e9968 Mon Sep 17 00:00:00 2001 > From: "Kirill A. Shutemov"> Date: Tue, 9 Jan 2018 02:55:47 +0300 > Subject: [PATCH] kdump: Write a correct address of mem_section into vmcoreinfo > > Depending on configuration mem_section can now be an array or a pointer > to an array allocated dynamically. In most cases, we can continue to refer > to it as 'mem_section' regardless of what it is. > > But there's one exception: '_section' means "address of the array" if > mem_section is an array, but if mem_section is a pointer, it would mean > "address of the pointer". > > We've stepped onto this in kdump code. VMCOREINFO_SYMBOL(mem_section) > writes down address of pointer into vmcoreinfo, not array as we wanted. > > Let's introduce VMCOREINFO_SYMBOL_ARRAY() that would handle the > situation correctly for both cases. > > Signed-off-by: Kirill A. Shutemov > Fixes: 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for > CONFIG_SPARSEMEM_EXTREME=y") > --- > include/linux/crash_core.h | 2 ++ > kernel/crash_core.c| 2 +- > 2 files changed, 3 insertions(+), 1 deletion(-) > > diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h > index 06097ef30449..b511f6d24b42 100644 > --- a/include/linux/crash_core.h > +++ b/include/linux/crash_core.h > @@ -42,6 +42,8 @@ phys_addr_t paddr_vmcoreinfo_note(void); > vmcoreinfo_append_str("PAGESIZE=%ld\n", value) > #define VMCOREINFO_SYMBOL(name) \ > vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)) > +#define VMCOREINFO_SYMBOL_ARRAY(name) \ > + vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)name) > #define VMCOREINFO_SIZE(name) \ > vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \ > (unsigned long)sizeof(name)) > diff --git a/kernel/crash_core.c b/kernel/crash_core.c > index b3663896278e..4f63597c824d 100644 > --- a/kernel/crash_core.c > +++ b/kernel/crash_core.c > @@ -410,7 +410,7 @@ static int __init crash_save_vmcoreinfo_init(void) > VMCOREINFO_SYMBOL(contig_page_data); > #endif > #ifdef CONFIG_SPARSEMEM > - VMCOREINFO_SYMBOL(mem_section); > + VMCOREINFO_SYMBOL_ARRAY(mem_section); > VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS); > VMCOREINFO_STRUCT_SIZE(mem_section); > VMCOREINFO_OFFSET(mem_section, section_mem_map); > -- > Kirill A. Shutemov Acked-by: Dave Young If stable kernel took the mem section commits, then should also cc stable. Andrew, can you help to make this in 4.15? Thanks Dave
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On 01/10/18 at 02:16pm, Kirill A. Shutemov wrote: > On Wed, Jan 10, 2018 at 03:08:04AM +, Dave Young wrote: > > On Tue, Jan 09, 2018 at 12:05:52PM +0300, Kirill A. Shutemov wrote: > > > On Tue, Jan 09, 2018 at 03:24:40PM +0800, Dave Young wrote: > > > > On 01/09/18 at 01:41pm, Baoquan He wrote: > > > > > On 01/09/18 at 09:09am, Dave Young wrote: > > > > > > > > > > > As for the macro name, VMCOREINFO_SYMBOL_ARRAY sounds better. > > > > > > Yep, that's better. > > > > > > > > I still think using vmcoreinfo_append_str is better. Unless we replace > > > > > all array variables with the newly added macro. > > > > > > > > > > vmcoreinfo_append_str("SYMBOL(mem_section)=%lx\n", > > > > > (unsigned long)mem_section); > > > > > > > > I have no strong opinion, either change all array uses or just introduce > > > > the macro and start to use it from now on if we have similar array > > > > symbols. > > > > > > Do you need some action on my side or will you folks take care about this? > > > > I think Baoquan was suggesting to update all array users in current > > code, if you can check every VMCOREINFO_SYMBOL and update all the arrays > > he will be happy. But if can not do it easily I'm fine with a > > VMCOREINFO_SYMBOL_ARRAY changes only now, we kdump people can do it > > later as well. > > It seems it's the only array we have there. swapper_pg_dir is a potential > candidate, but it's 'unsigned long' on arm. > > Below it patch with corrected macro name. > > Please, consider applying. > > From 70f3a84b97f2de98d1364f7b10b7a42a1d8e9968 Mon Sep 17 00:00:00 2001 > From: "Kirill A. Shutemov" > Date: Tue, 9 Jan 2018 02:55:47 +0300 > Subject: [PATCH] kdump: Write a correct address of mem_section into vmcoreinfo > > Depending on configuration mem_section can now be an array or a pointer > to an array allocated dynamically. In most cases, we can continue to refer > to it as 'mem_section' regardless of what it is. > > But there's one exception: '_section' means "address of the array" if > mem_section is an array, but if mem_section is a pointer, it would mean > "address of the pointer". > > We've stepped onto this in kdump code. VMCOREINFO_SYMBOL(mem_section) > writes down address of pointer into vmcoreinfo, not array as we wanted. > > Let's introduce VMCOREINFO_SYMBOL_ARRAY() that would handle the > situation correctly for both cases. > > Signed-off-by: Kirill A. Shutemov > Fixes: 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for > CONFIG_SPARSEMEM_EXTREME=y") > --- > include/linux/crash_core.h | 2 ++ > kernel/crash_core.c| 2 +- > 2 files changed, 3 insertions(+), 1 deletion(-) > > diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h > index 06097ef30449..b511f6d24b42 100644 > --- a/include/linux/crash_core.h > +++ b/include/linux/crash_core.h > @@ -42,6 +42,8 @@ phys_addr_t paddr_vmcoreinfo_note(void); > vmcoreinfo_append_str("PAGESIZE=%ld\n", value) > #define VMCOREINFO_SYMBOL(name) \ > vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)) > +#define VMCOREINFO_SYMBOL_ARRAY(name) \ > + vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)name) > #define VMCOREINFO_SIZE(name) \ > vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \ > (unsigned long)sizeof(name)) > diff --git a/kernel/crash_core.c b/kernel/crash_core.c > index b3663896278e..4f63597c824d 100644 > --- a/kernel/crash_core.c > +++ b/kernel/crash_core.c > @@ -410,7 +410,7 @@ static int __init crash_save_vmcoreinfo_init(void) > VMCOREINFO_SYMBOL(contig_page_data); > #endif > #ifdef CONFIG_SPARSEMEM > - VMCOREINFO_SYMBOL(mem_section); > + VMCOREINFO_SYMBOL_ARRAY(mem_section); > VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS); > VMCOREINFO_STRUCT_SIZE(mem_section); > VMCOREINFO_OFFSET(mem_section, section_mem_map); > -- > Kirill A. Shutemov Acked-by: Dave Young If stable kernel took the mem section commits, then should also cc stable. Andrew, can you help to make this in 4.15? Thanks Dave
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On 01/10/18 at 02:16pm, Kirill A. Shutemov wrote: > On Wed, Jan 10, 2018 at 03:08:04AM +, Dave Young wrote: > > On Tue, Jan 09, 2018 at 12:05:52PM +0300, Kirill A. Shutemov wrote: > > > On Tue, Jan 09, 2018 at 03:24:40PM +0800, Dave Young wrote: > > > > On 01/09/18 at 01:41pm, Baoquan He wrote: > > > > > On 01/09/18 at 09:09am, Dave Young wrote: > > > > > > > > > > > As for the macro name, VMCOREINFO_SYMBOL_ARRAY sounds better. > > > > > > Yep, that's better. > > > > > > > > I still think using vmcoreinfo_append_str is better. Unless we replace > > > > > all array variables with the newly added macro. > > > > > > > > > > vmcoreinfo_append_str("SYMBOL(mem_section)=%lx\n", > > > > > (unsigned long)mem_section); > > > > > > > > I have no strong opinion, either change all array uses or just introduce > > > > the macro and start to use it from now on if we have similar array > > > > symbols. > > > > > > Do you need some action on my side or will you folks take care about this? > > > > I think Baoquan was suggesting to update all array users in current > > code, if you can check every VMCOREINFO_SYMBOL and update all the arrays > > he will be happy. But if can not do it easily I'm fine with a > > VMCOREINFO_SYMBOL_ARRAY changes only now, we kdump people can do it > > later as well. > > It seems it's the only array we have there. swapper_pg_dir is a potential > candidate, but it's 'unsigned long' on arm. > > Below it patch with corrected macro name. > > Please, consider applying. > > From 70f3a84b97f2de98d1364f7b10b7a42a1d8e9968 Mon Sep 17 00:00:00 2001 > From: "Kirill A. Shutemov"> Date: Tue, 9 Jan 2018 02:55:47 +0300 > Subject: [PATCH] kdump: Write a correct address of mem_section into vmcoreinfo > > Depending on configuration mem_section can now be an array or a pointer > to an array allocated dynamically. In most cases, we can continue to refer > to it as 'mem_section' regardless of what it is. > > But there's one exception: '_section' means "address of the array" if > mem_section is an array, but if mem_section is a pointer, it would mean > "address of the pointer". > > We've stepped onto this in kdump code. VMCOREINFO_SYMBOL(mem_section) > writes down address of pointer into vmcoreinfo, not array as we wanted. > > Let's introduce VMCOREINFO_SYMBOL_ARRAY() that would handle the > situation correctly for both cases. > > Signed-off-by: Kirill A. Shutemov > Fixes: 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for > CONFIG_SPARSEMEM_EXTREME=y") Ack it, thanks. Acked-by: Baoquan He > --- > include/linux/crash_core.h | 2 ++ > kernel/crash_core.c| 2 +- > 2 files changed, 3 insertions(+), 1 deletion(-) > > diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h > index 06097ef30449..b511f6d24b42 100644 > --- a/include/linux/crash_core.h > +++ b/include/linux/crash_core.h > @@ -42,6 +42,8 @@ phys_addr_t paddr_vmcoreinfo_note(void); > vmcoreinfo_append_str("PAGESIZE=%ld\n", value) > #define VMCOREINFO_SYMBOL(name) \ > vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)) > +#define VMCOREINFO_SYMBOL_ARRAY(name) \ > + vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)name) > #define VMCOREINFO_SIZE(name) \ > vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \ > (unsigned long)sizeof(name)) > diff --git a/kernel/crash_core.c b/kernel/crash_core.c > index b3663896278e..4f63597c824d 100644 > --- a/kernel/crash_core.c > +++ b/kernel/crash_core.c > @@ -410,7 +410,7 @@ static int __init crash_save_vmcoreinfo_init(void) > VMCOREINFO_SYMBOL(contig_page_data); > #endif > #ifdef CONFIG_SPARSEMEM > - VMCOREINFO_SYMBOL(mem_section); > + VMCOREINFO_SYMBOL_ARRAY(mem_section); > VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS); > VMCOREINFO_STRUCT_SIZE(mem_section); > VMCOREINFO_OFFSET(mem_section, section_mem_map); > -- > Kirill A. Shutemov
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On 01/10/18 at 02:16pm, Kirill A. Shutemov wrote: > On Wed, Jan 10, 2018 at 03:08:04AM +, Dave Young wrote: > > On Tue, Jan 09, 2018 at 12:05:52PM +0300, Kirill A. Shutemov wrote: > > > On Tue, Jan 09, 2018 at 03:24:40PM +0800, Dave Young wrote: > > > > On 01/09/18 at 01:41pm, Baoquan He wrote: > > > > > On 01/09/18 at 09:09am, Dave Young wrote: > > > > > > > > > > > As for the macro name, VMCOREINFO_SYMBOL_ARRAY sounds better. > > > > > > Yep, that's better. > > > > > > > > I still think using vmcoreinfo_append_str is better. Unless we replace > > > > > all array variables with the newly added macro. > > > > > > > > > > vmcoreinfo_append_str("SYMBOL(mem_section)=%lx\n", > > > > > (unsigned long)mem_section); > > > > > > > > I have no strong opinion, either change all array uses or just introduce > > > > the macro and start to use it from now on if we have similar array > > > > symbols. > > > > > > Do you need some action on my side or will you folks take care about this? > > > > I think Baoquan was suggesting to update all array users in current > > code, if you can check every VMCOREINFO_SYMBOL and update all the arrays > > he will be happy. But if can not do it easily I'm fine with a > > VMCOREINFO_SYMBOL_ARRAY changes only now, we kdump people can do it > > later as well. > > It seems it's the only array we have there. swapper_pg_dir is a potential > candidate, but it's 'unsigned long' on arm. > > Below it patch with corrected macro name. > > Please, consider applying. > > From 70f3a84b97f2de98d1364f7b10b7a42a1d8e9968 Mon Sep 17 00:00:00 2001 > From: "Kirill A. Shutemov" > Date: Tue, 9 Jan 2018 02:55:47 +0300 > Subject: [PATCH] kdump: Write a correct address of mem_section into vmcoreinfo > > Depending on configuration mem_section can now be an array or a pointer > to an array allocated dynamically. In most cases, we can continue to refer > to it as 'mem_section' regardless of what it is. > > But there's one exception: '_section' means "address of the array" if > mem_section is an array, but if mem_section is a pointer, it would mean > "address of the pointer". > > We've stepped onto this in kdump code. VMCOREINFO_SYMBOL(mem_section) > writes down address of pointer into vmcoreinfo, not array as we wanted. > > Let's introduce VMCOREINFO_SYMBOL_ARRAY() that would handle the > situation correctly for both cases. > > Signed-off-by: Kirill A. Shutemov > Fixes: 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for > CONFIG_SPARSEMEM_EXTREME=y") Ack it, thanks. Acked-by: Baoquan He > --- > include/linux/crash_core.h | 2 ++ > kernel/crash_core.c| 2 +- > 2 files changed, 3 insertions(+), 1 deletion(-) > > diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h > index 06097ef30449..b511f6d24b42 100644 > --- a/include/linux/crash_core.h > +++ b/include/linux/crash_core.h > @@ -42,6 +42,8 @@ phys_addr_t paddr_vmcoreinfo_note(void); > vmcoreinfo_append_str("PAGESIZE=%ld\n", value) > #define VMCOREINFO_SYMBOL(name) \ > vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)) > +#define VMCOREINFO_SYMBOL_ARRAY(name) \ > + vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)name) > #define VMCOREINFO_SIZE(name) \ > vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \ > (unsigned long)sizeof(name)) > diff --git a/kernel/crash_core.c b/kernel/crash_core.c > index b3663896278e..4f63597c824d 100644 > --- a/kernel/crash_core.c > +++ b/kernel/crash_core.c > @@ -410,7 +410,7 @@ static int __init crash_save_vmcoreinfo_init(void) > VMCOREINFO_SYMBOL(contig_page_data); > #endif > #ifdef CONFIG_SPARSEMEM > - VMCOREINFO_SYMBOL(mem_section); > + VMCOREINFO_SYMBOL_ARRAY(mem_section); > VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS); > VMCOREINFO_STRUCT_SIZE(mem_section); > VMCOREINFO_OFFSET(mem_section, section_mem_map); > -- > Kirill A. Shutemov
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Wed, Jan 10, 2018 at 03:08:04AM +, Dave Young wrote: > On Tue, Jan 09, 2018 at 12:05:52PM +0300, Kirill A. Shutemov wrote: > > On Tue, Jan 09, 2018 at 03:24:40PM +0800, Dave Young wrote: > > > On 01/09/18 at 01:41pm, Baoquan He wrote: > > > > On 01/09/18 at 09:09am, Dave Young wrote: > > > > > > > > > As for the macro name, VMCOREINFO_SYMBOL_ARRAY sounds better. > > > > Yep, that's better. > > > > > > I still think using vmcoreinfo_append_str is better. Unless we replace > > > > all array variables with the newly added macro. > > > > > > > > vmcoreinfo_append_str("SYMBOL(mem_section)=%lx\n", > > > > (unsigned long)mem_section); > > > > > > I have no strong opinion, either change all array uses or just introduce > > > the macro and start to use it from now on if we have similar array > > > symbols. > > > > Do you need some action on my side or will you folks take care about this? > > I think Baoquan was suggesting to update all array users in current > code, if you can check every VMCOREINFO_SYMBOL and update all the arrays > he will be happy. But if can not do it easily I'm fine with a > VMCOREINFO_SYMBOL_ARRAY changes only now, we kdump people can do it > later as well. It seems it's the only array we have there. swapper_pg_dir is a potential candidate, but it's 'unsigned long' on arm. Below it patch with corrected macro name. Please, consider applying. >From 70f3a84b97f2de98d1364f7b10b7a42a1d8e9968 Mon Sep 17 00:00:00 2001 From: "Kirill A. Shutemov"Date: Tue, 9 Jan 2018 02:55:47 +0300 Subject: [PATCH] kdump: Write a correct address of mem_section into vmcoreinfo Depending on configuration mem_section can now be an array or a pointer to an array allocated dynamically. In most cases, we can continue to refer to it as 'mem_section' regardless of what it is. But there's one exception: '_section' means "address of the array" if mem_section is an array, but if mem_section is a pointer, it would mean "address of the pointer". We've stepped onto this in kdump code. VMCOREINFO_SYMBOL(mem_section) writes down address of pointer into vmcoreinfo, not array as we wanted. Let's introduce VMCOREINFO_SYMBOL_ARRAY() that would handle the situation correctly for both cases. Signed-off-by: Kirill A. Shutemov Fixes: 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y") --- include/linux/crash_core.h | 2 ++ kernel/crash_core.c| 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h index 06097ef30449..b511f6d24b42 100644 --- a/include/linux/crash_core.h +++ b/include/linux/crash_core.h @@ -42,6 +42,8 @@ phys_addr_t paddr_vmcoreinfo_note(void); vmcoreinfo_append_str("PAGESIZE=%ld\n", value) #define VMCOREINFO_SYMBOL(name) \ vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)) +#define VMCOREINFO_SYMBOL_ARRAY(name) \ + vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)name) #define VMCOREINFO_SIZE(name) \ vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \ (unsigned long)sizeof(name)) diff --git a/kernel/crash_core.c b/kernel/crash_core.c index b3663896278e..4f63597c824d 100644 --- a/kernel/crash_core.c +++ b/kernel/crash_core.c @@ -410,7 +410,7 @@ static int __init crash_save_vmcoreinfo_init(void) VMCOREINFO_SYMBOL(contig_page_data); #endif #ifdef CONFIG_SPARSEMEM - VMCOREINFO_SYMBOL(mem_section); + VMCOREINFO_SYMBOL_ARRAY(mem_section); VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS); VMCOREINFO_STRUCT_SIZE(mem_section); VMCOREINFO_OFFSET(mem_section, section_mem_map); -- Kirill A. Shutemov
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Wed, Jan 10, 2018 at 03:08:04AM +, Dave Young wrote: > On Tue, Jan 09, 2018 at 12:05:52PM +0300, Kirill A. Shutemov wrote: > > On Tue, Jan 09, 2018 at 03:24:40PM +0800, Dave Young wrote: > > > On 01/09/18 at 01:41pm, Baoquan He wrote: > > > > On 01/09/18 at 09:09am, Dave Young wrote: > > > > > > > > > As for the macro name, VMCOREINFO_SYMBOL_ARRAY sounds better. > > > > Yep, that's better. > > > > > > I still think using vmcoreinfo_append_str is better. Unless we replace > > > > all array variables with the newly added macro. > > > > > > > > vmcoreinfo_append_str("SYMBOL(mem_section)=%lx\n", > > > > (unsigned long)mem_section); > > > > > > I have no strong opinion, either change all array uses or just introduce > > > the macro and start to use it from now on if we have similar array > > > symbols. > > > > Do you need some action on my side or will you folks take care about this? > > I think Baoquan was suggesting to update all array users in current > code, if you can check every VMCOREINFO_SYMBOL and update all the arrays > he will be happy. But if can not do it easily I'm fine with a > VMCOREINFO_SYMBOL_ARRAY changes only now, we kdump people can do it > later as well. It seems it's the only array we have there. swapper_pg_dir is a potential candidate, but it's 'unsigned long' on arm. Below it patch with corrected macro name. Please, consider applying. >From 70f3a84b97f2de98d1364f7b10b7a42a1d8e9968 Mon Sep 17 00:00:00 2001 From: "Kirill A. Shutemov" Date: Tue, 9 Jan 2018 02:55:47 +0300 Subject: [PATCH] kdump: Write a correct address of mem_section into vmcoreinfo Depending on configuration mem_section can now be an array or a pointer to an array allocated dynamically. In most cases, we can continue to refer to it as 'mem_section' regardless of what it is. But there's one exception: '_section' means "address of the array" if mem_section is an array, but if mem_section is a pointer, it would mean "address of the pointer". We've stepped onto this in kdump code. VMCOREINFO_SYMBOL(mem_section) writes down address of pointer into vmcoreinfo, not array as we wanted. Let's introduce VMCOREINFO_SYMBOL_ARRAY() that would handle the situation correctly for both cases. Signed-off-by: Kirill A. Shutemov Fixes: 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y") --- include/linux/crash_core.h | 2 ++ kernel/crash_core.c| 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h index 06097ef30449..b511f6d24b42 100644 --- a/include/linux/crash_core.h +++ b/include/linux/crash_core.h @@ -42,6 +42,8 @@ phys_addr_t paddr_vmcoreinfo_note(void); vmcoreinfo_append_str("PAGESIZE=%ld\n", value) #define VMCOREINFO_SYMBOL(name) \ vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)) +#define VMCOREINFO_SYMBOL_ARRAY(name) \ + vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)name) #define VMCOREINFO_SIZE(name) \ vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \ (unsigned long)sizeof(name)) diff --git a/kernel/crash_core.c b/kernel/crash_core.c index b3663896278e..4f63597c824d 100644 --- a/kernel/crash_core.c +++ b/kernel/crash_core.c @@ -410,7 +410,7 @@ static int __init crash_save_vmcoreinfo_init(void) VMCOREINFO_SYMBOL(contig_page_data); #endif #ifdef CONFIG_SPARSEMEM - VMCOREINFO_SYMBOL(mem_section); + VMCOREINFO_SYMBOL_ARRAY(mem_section); VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS); VMCOREINFO_STRUCT_SIZE(mem_section); VMCOREINFO_OFFSET(mem_section, section_mem_map); -- Kirill A. Shutemov
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Tue, Jan 09, 2018 at 12:05:52PM +0300, Kirill A. Shutemov wrote: > On Tue, Jan 09, 2018 at 03:24:40PM +0800, Dave Young wrote: > > On 01/09/18 at 01:41pm, Baoquan He wrote: > > > On 01/09/18 at 09:09am, Dave Young wrote: > > > > > > > As for the macro name, VMCOREINFO_SYMBOL_ARRAY sounds better. > > Yep, that's better. > > > > I still think using vmcoreinfo_append_str is better. Unless we replace > > > all array variables with the newly added macro. > > > > > > vmcoreinfo_append_str("SYMBOL(mem_section)=%lx\n", > > > (unsigned long)mem_section); > > > > I have no strong opinion, either change all array uses or just introduce > > the macro and start to use it from now on if we have similar array > > symbols. > > Do you need some action on my side or will you folks take care about this? I think Baoquan was suggesting to update all array users in current code, if you can check every VMCOREINFO_SYMBOL and update all the arrays he will be happy. But if can not do it easily I'm fine with a VMCOREINFO_SYMBOL_ARRAY changes only now, we kdump people can do it later as well. > > -- > Kirill A. Shutemov Thanks Dave
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Tue, Jan 09, 2018 at 12:05:52PM +0300, Kirill A. Shutemov wrote: > On Tue, Jan 09, 2018 at 03:24:40PM +0800, Dave Young wrote: > > On 01/09/18 at 01:41pm, Baoquan He wrote: > > > On 01/09/18 at 09:09am, Dave Young wrote: > > > > > > > As for the macro name, VMCOREINFO_SYMBOL_ARRAY sounds better. > > Yep, that's better. > > > > I still think using vmcoreinfo_append_str is better. Unless we replace > > > all array variables with the newly added macro. > > > > > > vmcoreinfo_append_str("SYMBOL(mem_section)=%lx\n", > > > (unsigned long)mem_section); > > > > I have no strong opinion, either change all array uses or just introduce > > the macro and start to use it from now on if we have similar array > > symbols. > > Do you need some action on my side or will you folks take care about this? I think Baoquan was suggesting to update all array users in current code, if you can check every VMCOREINFO_SYMBOL and update all the arrays he will be happy. But if can not do it easily I'm fine with a VMCOREINFO_SYMBOL_ARRAY changes only now, we kdump people can do it later as well. > > -- > Kirill A. Shutemov Thanks Dave
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Tue, Jan 09, 2018 at 03:24:40PM +0800, Dave Young wrote: > On 01/09/18 at 01:41pm, Baoquan He wrote: > > On 01/09/18 at 09:09am, Dave Young wrote: > > > > > As for the macro name, VMCOREINFO_SYMBOL_ARRAY sounds better. Yep, that's better. > > I still think using vmcoreinfo_append_str is better. Unless we replace > > all array variables with the newly added macro. > > > > vmcoreinfo_append_str("SYMBOL(mem_section)=%lx\n", > > (unsigned long)mem_section); > > I have no strong opinion, either change all array uses or just introduce > the macro and start to use it from now on if we have similar array > symbols. Do you need some action on my side or will you folks take care about this? -- Kirill A. Shutemov
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Tue, Jan 09, 2018 at 03:24:40PM +0800, Dave Young wrote: > On 01/09/18 at 01:41pm, Baoquan He wrote: > > On 01/09/18 at 09:09am, Dave Young wrote: > > > > > As for the macro name, VMCOREINFO_SYMBOL_ARRAY sounds better. Yep, that's better. > > I still think using vmcoreinfo_append_str is better. Unless we replace > > all array variables with the newly added macro. > > > > vmcoreinfo_append_str("SYMBOL(mem_section)=%lx\n", > > (unsigned long)mem_section); > > I have no strong opinion, either change all array uses or just introduce > the macro and start to use it from now on if we have similar array > symbols. Do you need some action on my side or will you folks take care about this? -- Kirill A. Shutemov
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On 01/09/18 at 01:41pm, Baoquan He wrote: > On 01/09/18 at 09:09am, Dave Young wrote: > > On 01/09/18 at 03:13am, Kirill A. Shutemov wrote: > > > On Mon, Jan 08, 2018 at 08:46:53PM +0300, Kirill A. Shutemov wrote: > > > > On Mon, Jan 08, 2018 at 04:04:44PM +, Ingo Molnar wrote: > > > > > > > > > > hi Kirill, > > > > > > > > > > As Mike reported it below, your 5-level paging related upstream > > > > > commit > > > > > 83e3c48729d9 and all its followup fixes: > > > > > > > > > > 83e3c48729d9: mm/sparsemem: Allocate mem_section at runtime for > > > > > CONFIG_SPARSEMEM_EXTREME=y > > > > > 629a359bdb0e: mm/sparsemem: Fix ARM64 boot crash when > > > > > CONFIG_SPARSEMEM_EXTREME=y > > > > > d09cfbbfa0f7: mm/sparse.c: wrong allocation for mem_section > > > > > > > > > > ... still breaks kexec - and that now regresses -stable as well. > > > > > > > > > > Given that 5-level paging now syntactically depends on having this > > > > > commit, if we > > > > > fully revert this then we'll have to disable 5-level paging as well. > > > > > > This *should* help. > > > > > > Mike, could you test this? (On top of the rest of the fixes.) > > > > > > Sorry for the mess. > > > > > > From 100fd567754f1457be94732046aefca204c842d2 Mon Sep 17 00:00:00 2001 > > > From: "Kirill A. Shutemov"> > > Date: Tue, 9 Jan 2018 02:55:47 +0300 > > > Subject: [PATCH] kdump: Write a correct address of mem_section into > > > vmcoreinfo > > > > > > Depending on configuration mem_section can now be an array or a pointer > > > to an array allocated dynamically. In most cases, we can continue to refer > > > to it as 'mem_section' regardless of what it is. > > > > > > But there's one exception: '_section' means "address of the array" if > > > mem_section is an array, but if mem_section is a pointer, it would mean > > > "address of the pointer". > > > > > > We've stepped onto this in kdump code. VMCOREINFO_SYMBOL(mem_section) > > > writes down address of pointer into vmcoreinfo, not array as we wanted. > > > > > > Let's introduce VMCOREINFO_ARRAY() that would handle the situation > > > correctly for both cases. > > > > > > Signed-off-by: Kirill A. Shutemov > > > Fixes: 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for > > > CONFIG_SPARSEMEM_EXTREME=y") > > > --- > > > include/linux/crash_core.h | 2 ++ > > > kernel/crash_core.c| 2 +- > > > 2 files changed, 3 insertions(+), 1 deletion(-) > > > > > > diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h > > > index 06097ef30449..83ae04950269 100644 > > > --- a/include/linux/crash_core.h > > > +++ b/include/linux/crash_core.h > > > @@ -42,6 +42,8 @@ phys_addr_t paddr_vmcoreinfo_note(void); > > > vmcoreinfo_append_str("PAGESIZE=%ld\n", value) > > > #define VMCOREINFO_SYMBOL(name) \ > > > vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)) > > > +#define VMCOREINFO_ARRAY(name) \ > > > > Thanks for the patch, I have a similar patch but makedumpfile maintainer > > is looking at a userspace fix instead. > > Seems we should add lkml to CC next time so that people can watch it. Yes, agreed. > > > As for the macro name, VMCOREINFO_SYMBOL_ARRAY sounds better. > > I still think using vmcoreinfo_append_str is better. Unless we replace > all array variables with the newly added macro. > > vmcoreinfo_append_str("SYMBOL(mem_section)=%lx\n", > (unsigned long)mem_section); I have no strong opinion, either change all array uses or just introduce the macro and start to use it from now on if we have similar array symbols. > > > > > + vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)name) > > > #define VMCOREINFO_SIZE(name) \ > > > vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \ > > > (unsigned long)sizeof(name)) > > > diff --git a/kernel/crash_core.c b/kernel/crash_core.c > > > index b3663896278e..d4122a837477 100644 > > > --- a/kernel/crash_core.c > > > +++ b/kernel/crash_core.c > > > @@ -410,7 +410,7 @@ static int __init crash_save_vmcoreinfo_init(void) > > > VMCOREINFO_SYMBOL(contig_page_data); > > > #endif > > > #ifdef CONFIG_SPARSEMEM > > > - VMCOREINFO_SYMBOL(mem_section); > > > + VMCOREINFO_ARRAY(mem_section); > > > VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS); > > > VMCOREINFO_STRUCT_SIZE(mem_section); > > > VMCOREINFO_OFFSET(mem_section, section_mem_map); > > > -- > > > Kirill A. Shutemov > > > > Thanks > > Dave Thanks Dave
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On 01/09/18 at 01:41pm, Baoquan He wrote: > On 01/09/18 at 09:09am, Dave Young wrote: > > On 01/09/18 at 03:13am, Kirill A. Shutemov wrote: > > > On Mon, Jan 08, 2018 at 08:46:53PM +0300, Kirill A. Shutemov wrote: > > > > On Mon, Jan 08, 2018 at 04:04:44PM +, Ingo Molnar wrote: > > > > > > > > > > hi Kirill, > > > > > > > > > > As Mike reported it below, your 5-level paging related upstream > > > > > commit > > > > > 83e3c48729d9 and all its followup fixes: > > > > > > > > > > 83e3c48729d9: mm/sparsemem: Allocate mem_section at runtime for > > > > > CONFIG_SPARSEMEM_EXTREME=y > > > > > 629a359bdb0e: mm/sparsemem: Fix ARM64 boot crash when > > > > > CONFIG_SPARSEMEM_EXTREME=y > > > > > d09cfbbfa0f7: mm/sparse.c: wrong allocation for mem_section > > > > > > > > > > ... still breaks kexec - and that now regresses -stable as well. > > > > > > > > > > Given that 5-level paging now syntactically depends on having this > > > > > commit, if we > > > > > fully revert this then we'll have to disable 5-level paging as well. > > > > > > This *should* help. > > > > > > Mike, could you test this? (On top of the rest of the fixes.) > > > > > > Sorry for the mess. > > > > > > From 100fd567754f1457be94732046aefca204c842d2 Mon Sep 17 00:00:00 2001 > > > From: "Kirill A. Shutemov" > > > Date: Tue, 9 Jan 2018 02:55:47 +0300 > > > Subject: [PATCH] kdump: Write a correct address of mem_section into > > > vmcoreinfo > > > > > > Depending on configuration mem_section can now be an array or a pointer > > > to an array allocated dynamically. In most cases, we can continue to refer > > > to it as 'mem_section' regardless of what it is. > > > > > > But there's one exception: '_section' means "address of the array" if > > > mem_section is an array, but if mem_section is a pointer, it would mean > > > "address of the pointer". > > > > > > We've stepped onto this in kdump code. VMCOREINFO_SYMBOL(mem_section) > > > writes down address of pointer into vmcoreinfo, not array as we wanted. > > > > > > Let's introduce VMCOREINFO_ARRAY() that would handle the situation > > > correctly for both cases. > > > > > > Signed-off-by: Kirill A. Shutemov > > > Fixes: 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for > > > CONFIG_SPARSEMEM_EXTREME=y") > > > --- > > > include/linux/crash_core.h | 2 ++ > > > kernel/crash_core.c| 2 +- > > > 2 files changed, 3 insertions(+), 1 deletion(-) > > > > > > diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h > > > index 06097ef30449..83ae04950269 100644 > > > --- a/include/linux/crash_core.h > > > +++ b/include/linux/crash_core.h > > > @@ -42,6 +42,8 @@ phys_addr_t paddr_vmcoreinfo_note(void); > > > vmcoreinfo_append_str("PAGESIZE=%ld\n", value) > > > #define VMCOREINFO_SYMBOL(name) \ > > > vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)) > > > +#define VMCOREINFO_ARRAY(name) \ > > > > Thanks for the patch, I have a similar patch but makedumpfile maintainer > > is looking at a userspace fix instead. > > Seems we should add lkml to CC next time so that people can watch it. Yes, agreed. > > > As for the macro name, VMCOREINFO_SYMBOL_ARRAY sounds better. > > I still think using vmcoreinfo_append_str is better. Unless we replace > all array variables with the newly added macro. > > vmcoreinfo_append_str("SYMBOL(mem_section)=%lx\n", > (unsigned long)mem_section); I have no strong opinion, either change all array uses or just introduce the macro and start to use it from now on if we have similar array symbols. > > > > > + vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)name) > > > #define VMCOREINFO_SIZE(name) \ > > > vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \ > > > (unsigned long)sizeof(name)) > > > diff --git a/kernel/crash_core.c b/kernel/crash_core.c > > > index b3663896278e..d4122a837477 100644 > > > --- a/kernel/crash_core.c > > > +++ b/kernel/crash_core.c > > > @@ -410,7 +410,7 @@ static int __init crash_save_vmcoreinfo_init(void) > > > VMCOREINFO_SYMBOL(contig_page_data); > > > #endif > > > #ifdef CONFIG_SPARSEMEM > > > - VMCOREINFO_SYMBOL(mem_section); > > > + VMCOREINFO_ARRAY(mem_section); > > > VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS); > > > VMCOREINFO_STRUCT_SIZE(mem_section); > > > VMCOREINFO_OFFSET(mem_section, section_mem_map); > > > -- > > > Kirill A. Shutemov > > > > Thanks > > Dave Thanks Dave
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On 01/09/18 at 09:09am, Dave Young wrote: > On 01/09/18 at 03:13am, Kirill A. Shutemov wrote: > > On Mon, Jan 08, 2018 at 08:46:53PM +0300, Kirill A. Shutemov wrote: > > > On Mon, Jan 08, 2018 at 04:04:44PM +, Ingo Molnar wrote: > > > > > > > > hi Kirill, > > > > > > > > As Mike reported it below, your 5-level paging related upstream commit > > > > 83e3c48729d9 and all its followup fixes: > > > > > > > > 83e3c48729d9: mm/sparsemem: Allocate mem_section at runtime for > > > > CONFIG_SPARSEMEM_EXTREME=y > > > > 629a359bdb0e: mm/sparsemem: Fix ARM64 boot crash when > > > > CONFIG_SPARSEMEM_EXTREME=y > > > > d09cfbbfa0f7: mm/sparse.c: wrong allocation for mem_section > > > > > > > > ... still breaks kexec - and that now regresses -stable as well. > > > > > > > > Given that 5-level paging now syntactically depends on having this > > > > commit, if we > > > > fully revert this then we'll have to disable 5-level paging as well. > > > > This *should* help. > > > > Mike, could you test this? (On top of the rest of the fixes.) > > > > Sorry for the mess. > > > > From 100fd567754f1457be94732046aefca204c842d2 Mon Sep 17 00:00:00 2001 > > From: "Kirill A. Shutemov"> > Date: Tue, 9 Jan 2018 02:55:47 +0300 > > Subject: [PATCH] kdump: Write a correct address of mem_section into > > vmcoreinfo > > > > Depending on configuration mem_section can now be an array or a pointer > > to an array allocated dynamically. In most cases, we can continue to refer > > to it as 'mem_section' regardless of what it is. > > > > But there's one exception: '_section' means "address of the array" if > > mem_section is an array, but if mem_section is a pointer, it would mean > > "address of the pointer". > > > > We've stepped onto this in kdump code. VMCOREINFO_SYMBOL(mem_section) > > writes down address of pointer into vmcoreinfo, not array as we wanted. > > > > Let's introduce VMCOREINFO_ARRAY() that would handle the situation > > correctly for both cases. > > > > Signed-off-by: Kirill A. Shutemov > > Fixes: 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for > > CONFIG_SPARSEMEM_EXTREME=y") > > --- > > include/linux/crash_core.h | 2 ++ > > kernel/crash_core.c| 2 +- > > 2 files changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h > > index 06097ef30449..83ae04950269 100644 > > --- a/include/linux/crash_core.h > > +++ b/include/linux/crash_core.h > > @@ -42,6 +42,8 @@ phys_addr_t paddr_vmcoreinfo_note(void); > > vmcoreinfo_append_str("PAGESIZE=%ld\n", value) > > #define VMCOREINFO_SYMBOL(name) \ > > vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)) > > +#define VMCOREINFO_ARRAY(name) \ > > Thanks for the patch, I have a similar patch but makedumpfile maintainer > is looking at a userspace fix instead. Seems we should add lkml to CC next time so that people can watch it. > As for the macro name, VMCOREINFO_SYMBOL_ARRAY sounds better. I still think using vmcoreinfo_append_str is better. Unless we replace all array variables with the newly added macro. vmcoreinfo_append_str("SYMBOL(mem_section)=%lx\n", (unsigned long)mem_section); > > > + vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)name) > > #define VMCOREINFO_SIZE(name) \ > > vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \ > > (unsigned long)sizeof(name)) > > diff --git a/kernel/crash_core.c b/kernel/crash_core.c > > index b3663896278e..d4122a837477 100644 > > --- a/kernel/crash_core.c > > +++ b/kernel/crash_core.c > > @@ -410,7 +410,7 @@ static int __init crash_save_vmcoreinfo_init(void) > > VMCOREINFO_SYMBOL(contig_page_data); > > #endif > > #ifdef CONFIG_SPARSEMEM > > - VMCOREINFO_SYMBOL(mem_section); > > + VMCOREINFO_ARRAY(mem_section); > > VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS); > > VMCOREINFO_STRUCT_SIZE(mem_section); > > VMCOREINFO_OFFSET(mem_section, section_mem_map); > > -- > > Kirill A. Shutemov > > Thanks > Dave
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On 01/09/18 at 09:09am, Dave Young wrote: > On 01/09/18 at 03:13am, Kirill A. Shutemov wrote: > > On Mon, Jan 08, 2018 at 08:46:53PM +0300, Kirill A. Shutemov wrote: > > > On Mon, Jan 08, 2018 at 04:04:44PM +, Ingo Molnar wrote: > > > > > > > > hi Kirill, > > > > > > > > As Mike reported it below, your 5-level paging related upstream commit > > > > 83e3c48729d9 and all its followup fixes: > > > > > > > > 83e3c48729d9: mm/sparsemem: Allocate mem_section at runtime for > > > > CONFIG_SPARSEMEM_EXTREME=y > > > > 629a359bdb0e: mm/sparsemem: Fix ARM64 boot crash when > > > > CONFIG_SPARSEMEM_EXTREME=y > > > > d09cfbbfa0f7: mm/sparse.c: wrong allocation for mem_section > > > > > > > > ... still breaks kexec - and that now regresses -stable as well. > > > > > > > > Given that 5-level paging now syntactically depends on having this > > > > commit, if we > > > > fully revert this then we'll have to disable 5-level paging as well. > > > > This *should* help. > > > > Mike, could you test this? (On top of the rest of the fixes.) > > > > Sorry for the mess. > > > > From 100fd567754f1457be94732046aefca204c842d2 Mon Sep 17 00:00:00 2001 > > From: "Kirill A. Shutemov" > > Date: Tue, 9 Jan 2018 02:55:47 +0300 > > Subject: [PATCH] kdump: Write a correct address of mem_section into > > vmcoreinfo > > > > Depending on configuration mem_section can now be an array or a pointer > > to an array allocated dynamically. In most cases, we can continue to refer > > to it as 'mem_section' regardless of what it is. > > > > But there's one exception: '_section' means "address of the array" if > > mem_section is an array, but if mem_section is a pointer, it would mean > > "address of the pointer". > > > > We've stepped onto this in kdump code. VMCOREINFO_SYMBOL(mem_section) > > writes down address of pointer into vmcoreinfo, not array as we wanted. > > > > Let's introduce VMCOREINFO_ARRAY() that would handle the situation > > correctly for both cases. > > > > Signed-off-by: Kirill A. Shutemov > > Fixes: 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for > > CONFIG_SPARSEMEM_EXTREME=y") > > --- > > include/linux/crash_core.h | 2 ++ > > kernel/crash_core.c| 2 +- > > 2 files changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h > > index 06097ef30449..83ae04950269 100644 > > --- a/include/linux/crash_core.h > > +++ b/include/linux/crash_core.h > > @@ -42,6 +42,8 @@ phys_addr_t paddr_vmcoreinfo_note(void); > > vmcoreinfo_append_str("PAGESIZE=%ld\n", value) > > #define VMCOREINFO_SYMBOL(name) \ > > vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)) > > +#define VMCOREINFO_ARRAY(name) \ > > Thanks for the patch, I have a similar patch but makedumpfile maintainer > is looking at a userspace fix instead. Seems we should add lkml to CC next time so that people can watch it. > As for the macro name, VMCOREINFO_SYMBOL_ARRAY sounds better. I still think using vmcoreinfo_append_str is better. Unless we replace all array variables with the newly added macro. vmcoreinfo_append_str("SYMBOL(mem_section)=%lx\n", (unsigned long)mem_section); > > > + vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)name) > > #define VMCOREINFO_SIZE(name) \ > > vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \ > > (unsigned long)sizeof(name)) > > diff --git a/kernel/crash_core.c b/kernel/crash_core.c > > index b3663896278e..d4122a837477 100644 > > --- a/kernel/crash_core.c > > +++ b/kernel/crash_core.c > > @@ -410,7 +410,7 @@ static int __init crash_save_vmcoreinfo_init(void) > > VMCOREINFO_SYMBOL(contig_page_data); > > #endif > > #ifdef CONFIG_SPARSEMEM > > - VMCOREINFO_SYMBOL(mem_section); > > + VMCOREINFO_ARRAY(mem_section); > > VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS); > > VMCOREINFO_STRUCT_SIZE(mem_section); > > VMCOREINFO_OFFSET(mem_section, section_mem_map); > > -- > > Kirill A. Shutemov > > Thanks > Dave
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Tue, 2018-01-09 at 03:13 +0300, Kirill A. Shutemov wrote: > > Mike, could you test this? (On top of the rest of the fixes.) homer:..crash/2018-01-09-04:25 # ll total 1863604 -rw--- 1 root root 66255 Jan 9 04:25 dmesg.txt -rw-r--r-- 1 root root182 Jan 9 04:25 README.txt -rw-r--r-- 1 root root2818240 Jan 9 04:25 System.map-4.15.0.gb2cd1df-master -rw--- 1 root root 1832914928 Jan 9 04:25 vmcore -rw-r--r-- 1 root root 72514993 Jan 9 04:25 vmlinux-4.15.0.gb2cd1df-master.gz Yup, all better. > Sorry for the mess. (why, developers not installing shiny new bugs is a whole lot worse:) > From 100fd567754f1457be94732046aefca204c842d2 Mon Sep 17 00:00:00 2001 > From: "Kirill A. Shutemov"> Date: Tue, 9 Jan 2018 02:55:47 +0300 > Subject: [PATCH] kdump: Write a correct address of mem_section into vmcoreinfo > > Depending on configuration mem_section can now be an array or a pointer > to an array allocated dynamically. In most cases, we can continue to refer > to it as 'mem_section' regardless of what it is. > > But there's one exception: '_section' means "address of the array" if > mem_section is an array, but if mem_section is a pointer, it would mean > "address of the pointer". > > We've stepped onto this in kdump code. VMCOREINFO_SYMBOL(mem_section) > writes down address of pointer into vmcoreinfo, not array as we wanted. > > Let's introduce VMCOREINFO_ARRAY() that would handle the situation > correctly for both cases. > > Signed-off-by: Kirill A. Shutemov > Fixes: 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for > CONFIG_SPARSEMEM_EXTREME=y") > --- > include/linux/crash_core.h | 2 ++ > kernel/crash_core.c| 2 +- > 2 files changed, 3 insertions(+), 1 deletion(-) > > diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h > index 06097ef30449..83ae04950269 100644 > --- a/include/linux/crash_core.h > +++ b/include/linux/crash_core.h > @@ -42,6 +42,8 @@ phys_addr_t paddr_vmcoreinfo_note(void); > vmcoreinfo_append_str("PAGESIZE=%ld\n", value) > #define VMCOREINFO_SYMBOL(name) \ > vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)) > +#define VMCOREINFO_ARRAY(name) \ > + vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)name) > #define VMCOREINFO_SIZE(name) \ > vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \ > (unsigned long)sizeof(name)) > diff --git a/kernel/crash_core.c b/kernel/crash_core.c > index b3663896278e..d4122a837477 100644 > --- a/kernel/crash_core.c > +++ b/kernel/crash_core.c > @@ -410,7 +410,7 @@ static int __init crash_save_vmcoreinfo_init(void) > VMCOREINFO_SYMBOL(contig_page_data); > #endif > #ifdef CONFIG_SPARSEMEM > - VMCOREINFO_SYMBOL(mem_section); > + VMCOREINFO_ARRAY(mem_section); > VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS); > VMCOREINFO_STRUCT_SIZE(mem_section); > VMCOREINFO_OFFSET(mem_section, section_mem_map);
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Tue, 2018-01-09 at 03:13 +0300, Kirill A. Shutemov wrote: > > Mike, could you test this? (On top of the rest of the fixes.) homer:..crash/2018-01-09-04:25 # ll total 1863604 -rw--- 1 root root 66255 Jan 9 04:25 dmesg.txt -rw-r--r-- 1 root root182 Jan 9 04:25 README.txt -rw-r--r-- 1 root root2818240 Jan 9 04:25 System.map-4.15.0.gb2cd1df-master -rw--- 1 root root 1832914928 Jan 9 04:25 vmcore -rw-r--r-- 1 root root 72514993 Jan 9 04:25 vmlinux-4.15.0.gb2cd1df-master.gz Yup, all better. > Sorry for the mess. (why, developers not installing shiny new bugs is a whole lot worse:) > From 100fd567754f1457be94732046aefca204c842d2 Mon Sep 17 00:00:00 2001 > From: "Kirill A. Shutemov" > Date: Tue, 9 Jan 2018 02:55:47 +0300 > Subject: [PATCH] kdump: Write a correct address of mem_section into vmcoreinfo > > Depending on configuration mem_section can now be an array or a pointer > to an array allocated dynamically. In most cases, we can continue to refer > to it as 'mem_section' regardless of what it is. > > But there's one exception: '_section' means "address of the array" if > mem_section is an array, but if mem_section is a pointer, it would mean > "address of the pointer". > > We've stepped onto this in kdump code. VMCOREINFO_SYMBOL(mem_section) > writes down address of pointer into vmcoreinfo, not array as we wanted. > > Let's introduce VMCOREINFO_ARRAY() that would handle the situation > correctly for both cases. > > Signed-off-by: Kirill A. Shutemov > Fixes: 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for > CONFIG_SPARSEMEM_EXTREME=y") > --- > include/linux/crash_core.h | 2 ++ > kernel/crash_core.c| 2 +- > 2 files changed, 3 insertions(+), 1 deletion(-) > > diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h > index 06097ef30449..83ae04950269 100644 > --- a/include/linux/crash_core.h > +++ b/include/linux/crash_core.h > @@ -42,6 +42,8 @@ phys_addr_t paddr_vmcoreinfo_note(void); > vmcoreinfo_append_str("PAGESIZE=%ld\n", value) > #define VMCOREINFO_SYMBOL(name) \ > vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)) > +#define VMCOREINFO_ARRAY(name) \ > + vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)name) > #define VMCOREINFO_SIZE(name) \ > vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \ > (unsigned long)sizeof(name)) > diff --git a/kernel/crash_core.c b/kernel/crash_core.c > index b3663896278e..d4122a837477 100644 > --- a/kernel/crash_core.c > +++ b/kernel/crash_core.c > @@ -410,7 +410,7 @@ static int __init crash_save_vmcoreinfo_init(void) > VMCOREINFO_SYMBOL(contig_page_data); > #endif > #ifdef CONFIG_SPARSEMEM > - VMCOREINFO_SYMBOL(mem_section); > + VMCOREINFO_ARRAY(mem_section); > VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS); > VMCOREINFO_STRUCT_SIZE(mem_section); > VMCOREINFO_OFFSET(mem_section, section_mem_map);
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On 01/09/18 at 03:13am, Kirill A. Shutemov wrote: > On Mon, Jan 08, 2018 at 08:46:53PM +0300, Kirill A. Shutemov wrote: > > On Mon, Jan 08, 2018 at 04:04:44PM +, Ingo Molnar wrote: > > > > > > hi Kirill, > > > > > > As Mike reported it below, your 5-level paging related upstream commit > > > 83e3c48729d9 and all its followup fixes: > > > > > > 83e3c48729d9: mm/sparsemem: Allocate mem_section at runtime for > > > CONFIG_SPARSEMEM_EXTREME=y > > > 629a359bdb0e: mm/sparsemem: Fix ARM64 boot crash when > > > CONFIG_SPARSEMEM_EXTREME=y > > > d09cfbbfa0f7: mm/sparse.c: wrong allocation for mem_section > > > > > > ... still breaks kexec - and that now regresses -stable as well. > > > > > > Given that 5-level paging now syntactically depends on having this > > > commit, if we > > > fully revert this then we'll have to disable 5-level paging as well. > > This *should* help. > > Mike, could you test this? (On top of the rest of the fixes.) > > Sorry for the mess. > > From 100fd567754f1457be94732046aefca204c842d2 Mon Sep 17 00:00:00 2001 > From: "Kirill A. Shutemov"> Date: Tue, 9 Jan 2018 02:55:47 +0300 > Subject: [PATCH] kdump: Write a correct address of mem_section into vmcoreinfo > > Depending on configuration mem_section can now be an array or a pointer > to an array allocated dynamically. In most cases, we can continue to refer > to it as 'mem_section' regardless of what it is. > > But there's one exception: '_section' means "address of the array" if > mem_section is an array, but if mem_section is a pointer, it would mean > "address of the pointer". > > We've stepped onto this in kdump code. VMCOREINFO_SYMBOL(mem_section) > writes down address of pointer into vmcoreinfo, not array as we wanted. > > Let's introduce VMCOREINFO_ARRAY() that would handle the situation > correctly for both cases. > > Signed-off-by: Kirill A. Shutemov > Fixes: 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for > CONFIG_SPARSEMEM_EXTREME=y") > --- > include/linux/crash_core.h | 2 ++ > kernel/crash_core.c| 2 +- > 2 files changed, 3 insertions(+), 1 deletion(-) > > diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h > index 06097ef30449..83ae04950269 100644 > --- a/include/linux/crash_core.h > +++ b/include/linux/crash_core.h > @@ -42,6 +42,8 @@ phys_addr_t paddr_vmcoreinfo_note(void); > vmcoreinfo_append_str("PAGESIZE=%ld\n", value) > #define VMCOREINFO_SYMBOL(name) \ > vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)) > +#define VMCOREINFO_ARRAY(name) \ Thanks for the patch, I have a similar patch but makedumpfile maintainer is looking at a userspace fix instead. As for the macro name, VMCOREINFO_SYMBOL_ARRAY sounds better. > + vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)name) > #define VMCOREINFO_SIZE(name) \ > vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \ > (unsigned long)sizeof(name)) > diff --git a/kernel/crash_core.c b/kernel/crash_core.c > index b3663896278e..d4122a837477 100644 > --- a/kernel/crash_core.c > +++ b/kernel/crash_core.c > @@ -410,7 +410,7 @@ static int __init crash_save_vmcoreinfo_init(void) > VMCOREINFO_SYMBOL(contig_page_data); > #endif > #ifdef CONFIG_SPARSEMEM > - VMCOREINFO_SYMBOL(mem_section); > + VMCOREINFO_ARRAY(mem_section); > VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS); > VMCOREINFO_STRUCT_SIZE(mem_section); > VMCOREINFO_OFFSET(mem_section, section_mem_map); > -- > Kirill A. Shutemov Thanks Dave
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On 01/09/18 at 03:13am, Kirill A. Shutemov wrote: > On Mon, Jan 08, 2018 at 08:46:53PM +0300, Kirill A. Shutemov wrote: > > On Mon, Jan 08, 2018 at 04:04:44PM +, Ingo Molnar wrote: > > > > > > hi Kirill, > > > > > > As Mike reported it below, your 5-level paging related upstream commit > > > 83e3c48729d9 and all its followup fixes: > > > > > > 83e3c48729d9: mm/sparsemem: Allocate mem_section at runtime for > > > CONFIG_SPARSEMEM_EXTREME=y > > > 629a359bdb0e: mm/sparsemem: Fix ARM64 boot crash when > > > CONFIG_SPARSEMEM_EXTREME=y > > > d09cfbbfa0f7: mm/sparse.c: wrong allocation for mem_section > > > > > > ... still breaks kexec - and that now regresses -stable as well. > > > > > > Given that 5-level paging now syntactically depends on having this > > > commit, if we > > > fully revert this then we'll have to disable 5-level paging as well. > > This *should* help. > > Mike, could you test this? (On top of the rest of the fixes.) > > Sorry for the mess. > > From 100fd567754f1457be94732046aefca204c842d2 Mon Sep 17 00:00:00 2001 > From: "Kirill A. Shutemov" > Date: Tue, 9 Jan 2018 02:55:47 +0300 > Subject: [PATCH] kdump: Write a correct address of mem_section into vmcoreinfo > > Depending on configuration mem_section can now be an array or a pointer > to an array allocated dynamically. In most cases, we can continue to refer > to it as 'mem_section' regardless of what it is. > > But there's one exception: '_section' means "address of the array" if > mem_section is an array, but if mem_section is a pointer, it would mean > "address of the pointer". > > We've stepped onto this in kdump code. VMCOREINFO_SYMBOL(mem_section) > writes down address of pointer into vmcoreinfo, not array as we wanted. > > Let's introduce VMCOREINFO_ARRAY() that would handle the situation > correctly for both cases. > > Signed-off-by: Kirill A. Shutemov > Fixes: 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for > CONFIG_SPARSEMEM_EXTREME=y") > --- > include/linux/crash_core.h | 2 ++ > kernel/crash_core.c| 2 +- > 2 files changed, 3 insertions(+), 1 deletion(-) > > diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h > index 06097ef30449..83ae04950269 100644 > --- a/include/linux/crash_core.h > +++ b/include/linux/crash_core.h > @@ -42,6 +42,8 @@ phys_addr_t paddr_vmcoreinfo_note(void); > vmcoreinfo_append_str("PAGESIZE=%ld\n", value) > #define VMCOREINFO_SYMBOL(name) \ > vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)) > +#define VMCOREINFO_ARRAY(name) \ Thanks for the patch, I have a similar patch but makedumpfile maintainer is looking at a userspace fix instead. As for the macro name, VMCOREINFO_SYMBOL_ARRAY sounds better. > + vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)name) > #define VMCOREINFO_SIZE(name) \ > vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \ > (unsigned long)sizeof(name)) > diff --git a/kernel/crash_core.c b/kernel/crash_core.c > index b3663896278e..d4122a837477 100644 > --- a/kernel/crash_core.c > +++ b/kernel/crash_core.c > @@ -410,7 +410,7 @@ static int __init crash_save_vmcoreinfo_init(void) > VMCOREINFO_SYMBOL(contig_page_data); > #endif > #ifdef CONFIG_SPARSEMEM > - VMCOREINFO_SYMBOL(mem_section); > + VMCOREINFO_ARRAY(mem_section); > VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS); > VMCOREINFO_STRUCT_SIZE(mem_section); > VMCOREINFO_OFFSET(mem_section, section_mem_map); > -- > Kirill A. Shutemov Thanks Dave
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Mon, Jan 08, 2018 at 08:46:53PM +0300, Kirill A. Shutemov wrote: > On Mon, Jan 08, 2018 at 04:04:44PM +, Ingo Molnar wrote: > > > > hi Kirill, > > > > As Mike reported it below, your 5-level paging related upstream commit > > 83e3c48729d9 and all its followup fixes: > > > > 83e3c48729d9: mm/sparsemem: Allocate mem_section at runtime for > > CONFIG_SPARSEMEM_EXTREME=y > > 629a359bdb0e: mm/sparsemem: Fix ARM64 boot crash when > > CONFIG_SPARSEMEM_EXTREME=y > > d09cfbbfa0f7: mm/sparse.c: wrong allocation for mem_section > > > > ... still breaks kexec - and that now regresses -stable as well. > > > > Given that 5-level paging now syntactically depends on having this commit, > > if we > > fully revert this then we'll have to disable 5-level paging as well. This *should* help. Mike, could you test this? (On top of the rest of the fixes.) Sorry for the mess. >From 100fd567754f1457be94732046aefca204c842d2 Mon Sep 17 00:00:00 2001 From: "Kirill A. Shutemov"Date: Tue, 9 Jan 2018 02:55:47 +0300 Subject: [PATCH] kdump: Write a correct address of mem_section into vmcoreinfo Depending on configuration mem_section can now be an array or a pointer to an array allocated dynamically. In most cases, we can continue to refer to it as 'mem_section' regardless of what it is. But there's one exception: '_section' means "address of the array" if mem_section is an array, but if mem_section is a pointer, it would mean "address of the pointer". We've stepped onto this in kdump code. VMCOREINFO_SYMBOL(mem_section) writes down address of pointer into vmcoreinfo, not array as we wanted. Let's introduce VMCOREINFO_ARRAY() that would handle the situation correctly for both cases. Signed-off-by: Kirill A. Shutemov Fixes: 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y") --- include/linux/crash_core.h | 2 ++ kernel/crash_core.c| 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h index 06097ef30449..83ae04950269 100644 --- a/include/linux/crash_core.h +++ b/include/linux/crash_core.h @@ -42,6 +42,8 @@ phys_addr_t paddr_vmcoreinfo_note(void); vmcoreinfo_append_str("PAGESIZE=%ld\n", value) #define VMCOREINFO_SYMBOL(name) \ vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)) +#define VMCOREINFO_ARRAY(name) \ + vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)name) #define VMCOREINFO_SIZE(name) \ vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \ (unsigned long)sizeof(name)) diff --git a/kernel/crash_core.c b/kernel/crash_core.c index b3663896278e..d4122a837477 100644 --- a/kernel/crash_core.c +++ b/kernel/crash_core.c @@ -410,7 +410,7 @@ static int __init crash_save_vmcoreinfo_init(void) VMCOREINFO_SYMBOL(contig_page_data); #endif #ifdef CONFIG_SPARSEMEM - VMCOREINFO_SYMBOL(mem_section); + VMCOREINFO_ARRAY(mem_section); VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS); VMCOREINFO_STRUCT_SIZE(mem_section); VMCOREINFO_OFFSET(mem_section, section_mem_map); -- Kirill A. Shutemov
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Mon, Jan 08, 2018 at 08:46:53PM +0300, Kirill A. Shutemov wrote: > On Mon, Jan 08, 2018 at 04:04:44PM +, Ingo Molnar wrote: > > > > hi Kirill, > > > > As Mike reported it below, your 5-level paging related upstream commit > > 83e3c48729d9 and all its followup fixes: > > > > 83e3c48729d9: mm/sparsemem: Allocate mem_section at runtime for > > CONFIG_SPARSEMEM_EXTREME=y > > 629a359bdb0e: mm/sparsemem: Fix ARM64 boot crash when > > CONFIG_SPARSEMEM_EXTREME=y > > d09cfbbfa0f7: mm/sparse.c: wrong allocation for mem_section > > > > ... still breaks kexec - and that now regresses -stable as well. > > > > Given that 5-level paging now syntactically depends on having this commit, > > if we > > fully revert this then we'll have to disable 5-level paging as well. This *should* help. Mike, could you test this? (On top of the rest of the fixes.) Sorry for the mess. >From 100fd567754f1457be94732046aefca204c842d2 Mon Sep 17 00:00:00 2001 From: "Kirill A. Shutemov" Date: Tue, 9 Jan 2018 02:55:47 +0300 Subject: [PATCH] kdump: Write a correct address of mem_section into vmcoreinfo Depending on configuration mem_section can now be an array or a pointer to an array allocated dynamically. In most cases, we can continue to refer to it as 'mem_section' regardless of what it is. But there's one exception: '_section' means "address of the array" if mem_section is an array, but if mem_section is a pointer, it would mean "address of the pointer". We've stepped onto this in kdump code. VMCOREINFO_SYMBOL(mem_section) writes down address of pointer into vmcoreinfo, not array as we wanted. Let's introduce VMCOREINFO_ARRAY() that would handle the situation correctly for both cases. Signed-off-by: Kirill A. Shutemov Fixes: 83e3c48729d9 ("mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y") --- include/linux/crash_core.h | 2 ++ kernel/crash_core.c| 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h index 06097ef30449..83ae04950269 100644 --- a/include/linux/crash_core.h +++ b/include/linux/crash_core.h @@ -42,6 +42,8 @@ phys_addr_t paddr_vmcoreinfo_note(void); vmcoreinfo_append_str("PAGESIZE=%ld\n", value) #define VMCOREINFO_SYMBOL(name) \ vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)) +#define VMCOREINFO_ARRAY(name) \ + vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long)name) #define VMCOREINFO_SIZE(name) \ vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \ (unsigned long)sizeof(name)) diff --git a/kernel/crash_core.c b/kernel/crash_core.c index b3663896278e..d4122a837477 100644 --- a/kernel/crash_core.c +++ b/kernel/crash_core.c @@ -410,7 +410,7 @@ static int __init crash_save_vmcoreinfo_init(void) VMCOREINFO_SYMBOL(contig_page_data); #endif #ifdef CONFIG_SPARSEMEM - VMCOREINFO_SYMBOL(mem_section); + VMCOREINFO_ARRAY(mem_section); VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS); VMCOREINFO_STRUCT_SIZE(mem_section); VMCOREINFO_OFFSET(mem_section, section_mem_map); -- Kirill A. Shutemov
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Mon, Jan 08, 2018 at 04:04:44PM +, Ingo Molnar wrote: > > hi Kirill, > > As Mike reported it below, your 5-level paging related upstream commit > 83e3c48729d9 and all its followup fixes: > > 83e3c48729d9: mm/sparsemem: Allocate mem_section at runtime for > CONFIG_SPARSEMEM_EXTREME=y > 629a359bdb0e: mm/sparsemem: Fix ARM64 boot crash when > CONFIG_SPARSEMEM_EXTREME=y > d09cfbbfa0f7: mm/sparse.c: wrong allocation for mem_section > > ... still breaks kexec - and that now regresses -stable as well. > > Given that 5-level paging now syntactically depends on having this commit, if > we > fully revert this then we'll have to disable 5-level paging as well. Urghh.. Sorry about this. I'm on vacation right now. Give me a day to sort this out. -- Kirill A. Shutemov
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Mon, Jan 08, 2018 at 04:04:44PM +, Ingo Molnar wrote: > > hi Kirill, > > As Mike reported it below, your 5-level paging related upstream commit > 83e3c48729d9 and all its followup fixes: > > 83e3c48729d9: mm/sparsemem: Allocate mem_section at runtime for > CONFIG_SPARSEMEM_EXTREME=y > 629a359bdb0e: mm/sparsemem: Fix ARM64 boot crash when > CONFIG_SPARSEMEM_EXTREME=y > d09cfbbfa0f7: mm/sparse.c: wrong allocation for mem_section > > ... still breaks kexec - and that now regresses -stable as well. > > Given that 5-level paging now syntactically depends on having this commit, if > we > fully revert this then we'll have to disable 5-level paging as well. Urghh.. Sorry about this. I'm on vacation right now. Give me a day to sort this out. -- Kirill A. Shutemov
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
hi Kirill, As Mike reported it below, your 5-level paging related upstream commit 83e3c48729d9 and all its followup fixes: 83e3c48729d9: mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y 629a359bdb0e: mm/sparsemem: Fix ARM64 boot crash when CONFIG_SPARSEMEM_EXTREME=y d09cfbbfa0f7: mm/sparse.c: wrong allocation for mem_section ... still breaks kexec - and that now regresses -stable as well. Given that 5-level paging now syntactically depends on having this commit, if we fully revert this then we'll have to disable 5-level paging as well. Thanks, Ingo * Mike Galbraithwrote: > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote: > > 4.14-stable review patch. If anyone has any objections, please let me know. > > FYI, this broke kdump, or rather the makedumpfile part thereof. > Forward looking wreckage is par for the kdump course, but... > > > -- > > > > From: Kirill A. Shutemov > > > > commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 upstream. > > > > Size of the mem_section[] array depends on the size of the physical address > > space. > > > > In preparation for boot-time switching between paging modes on x86-64 > > we need to make the allocation of mem_section[] dynamic, because otherwise > > we waste a lot of RAM: with CONFIG_NODE_SHIFT=10, mem_section[] size is 32kB > > for 4-level paging and 2MB for 5-level paging mode. > > > > The patch allocates the array on the first call to > > sparse_memory_present_with_active_regions(). > > > > Signed-off-by: Kirill A. Shutemov > > Cc: Andrew Morton > > Cc: Andy Lutomirski > > Cc: Borislav Petkov > > Cc: Cyrill Gorcunov > > Cc: Linus Torvalds > > Cc: Peter Zijlstra > > Cc: Thomas Gleixner > > Cc: linux...@kvack.org > > Link: > > http://lkml.kernel.org/r/20170929140821.37654-2-kirill.shute...@linux.intel.com > > Signed-off-by: Ingo Molnar > > Signed-off-by: Greg Kroah-Hartman > > > > --- > > include/linux/mmzone.h |6 +- > > mm/page_alloc.c| 10 ++ > > mm/sparse.c| 17 +++-- > > 3 files changed, 26 insertions(+), 7 deletions(-) > > > > --- a/include/linux/mmzone.h > > +++ b/include/linux/mmzone.h > > @@ -1152,13 +1152,17 @@ struct mem_section { > > #define SECTION_ROOT_MASK (SECTIONS_PER_ROOT - 1) > > > > #ifdef CONFIG_SPARSEMEM_EXTREME > > -extern struct mem_section *mem_section[NR_SECTION_ROOTS]; > > +extern struct mem_section **mem_section; > > #else > > extern struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT]; > > #endif > > > > static inline struct mem_section *__nr_to_section(unsigned long nr) > > { > > +#ifdef CONFIG_SPARSEMEM_EXTREME > > + if (!mem_section) > > + return NULL; > > +#endif > > if (!mem_section[SECTION_NR_TO_ROOT(nr)]) > > return NULL; > > return _section[SECTION_NR_TO_ROOT(nr)][nr & SECTION_ROOT_MASK]; > > --- a/mm/page_alloc.c > > +++ b/mm/page_alloc.c > > @@ -5651,6 +5651,16 @@ void __init sparse_memory_present_with_a > > unsigned long start_pfn, end_pfn; > > int i, this_nid; > > > > +#ifdef CONFIG_SPARSEMEM_EXTREME > > + if (!mem_section) { > > + unsigned long size, align; > > + > > + size = sizeof(struct mem_section) * NR_SECTION_ROOTS; > > + align = 1 << (INTERNODE_CACHE_SHIFT); > > + mem_section = memblock_virt_alloc(size, align); > > + } > > +#endif > > + > > for_each_mem_pfn_range(i, nid, _pfn, _pfn, _nid) > > memory_present(this_nid, start_pfn, end_pfn); > > } > > --- a/mm/sparse.c > > +++ b/mm/sparse.c > > @@ -23,8 +23,7 @@ > > * 1) mem_section - memory sections, mem_map's for valid memory > > */ > > #ifdef CONFIG_SPARSEMEM_EXTREME > > -struct mem_section *mem_section[NR_SECTION_ROOTS] > > - cacheline_internodealigned_in_smp; > > +struct mem_section **mem_section; > > #else > > struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT] > > cacheline_internodealigned_in_smp; > > @@ -101,7 +100,7 @@ static inline int sparse_index_init(unsi > > int __section_nr(struct mem_section* ms) > > { > > unsigned long root_nr; > > - struct mem_section* root; > > + struct mem_section *root = NULL; > > > > for (root_nr = 0; root_nr < NR_SECTION_ROOTS; root_nr++) { > > root = __nr_to_section(root_nr * SECTIONS_PER_ROOT); > > @@ -112,7 +111,7 @@ int __section_nr(struct mem_section* ms) > > break; > > } > > > > - VM_BUG_ON(root_nr == NR_SECTION_ROOTS); > > + VM_BUG_ON(!root); > > > > return (root_nr * SECTIONS_PER_ROOT) + (ms - root); > > } > > @@ -330,11 +329,17 @@ again: > > static void __init
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
hi Kirill, As Mike reported it below, your 5-level paging related upstream commit 83e3c48729d9 and all its followup fixes: 83e3c48729d9: mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y 629a359bdb0e: mm/sparsemem: Fix ARM64 boot crash when CONFIG_SPARSEMEM_EXTREME=y d09cfbbfa0f7: mm/sparse.c: wrong allocation for mem_section ... still breaks kexec - and that now regresses -stable as well. Given that 5-level paging now syntactically depends on having this commit, if we fully revert this then we'll have to disable 5-level paging as well. Thanks, Ingo * Mike Galbraith wrote: > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote: > > 4.14-stable review patch. If anyone has any objections, please let me know. > > FYI, this broke kdump, or rather the makedumpfile part thereof. > Forward looking wreckage is par for the kdump course, but... > > > -- > > > > From: Kirill A. Shutemov > > > > commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 upstream. > > > > Size of the mem_section[] array depends on the size of the physical address > > space. > > > > In preparation for boot-time switching between paging modes on x86-64 > > we need to make the allocation of mem_section[] dynamic, because otherwise > > we waste a lot of RAM: with CONFIG_NODE_SHIFT=10, mem_section[] size is 32kB > > for 4-level paging and 2MB for 5-level paging mode. > > > > The patch allocates the array on the first call to > > sparse_memory_present_with_active_regions(). > > > > Signed-off-by: Kirill A. Shutemov > > Cc: Andrew Morton > > Cc: Andy Lutomirski > > Cc: Borislav Petkov > > Cc: Cyrill Gorcunov > > Cc: Linus Torvalds > > Cc: Peter Zijlstra > > Cc: Thomas Gleixner > > Cc: linux...@kvack.org > > Link: > > http://lkml.kernel.org/r/20170929140821.37654-2-kirill.shute...@linux.intel.com > > Signed-off-by: Ingo Molnar > > Signed-off-by: Greg Kroah-Hartman > > > > --- > > include/linux/mmzone.h |6 +- > > mm/page_alloc.c| 10 ++ > > mm/sparse.c| 17 +++-- > > 3 files changed, 26 insertions(+), 7 deletions(-) > > > > --- a/include/linux/mmzone.h > > +++ b/include/linux/mmzone.h > > @@ -1152,13 +1152,17 @@ struct mem_section { > > #define SECTION_ROOT_MASK (SECTIONS_PER_ROOT - 1) > > > > #ifdef CONFIG_SPARSEMEM_EXTREME > > -extern struct mem_section *mem_section[NR_SECTION_ROOTS]; > > +extern struct mem_section **mem_section; > > #else > > extern struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT]; > > #endif > > > > static inline struct mem_section *__nr_to_section(unsigned long nr) > > { > > +#ifdef CONFIG_SPARSEMEM_EXTREME > > + if (!mem_section) > > + return NULL; > > +#endif > > if (!mem_section[SECTION_NR_TO_ROOT(nr)]) > > return NULL; > > return _section[SECTION_NR_TO_ROOT(nr)][nr & SECTION_ROOT_MASK]; > > --- a/mm/page_alloc.c > > +++ b/mm/page_alloc.c > > @@ -5651,6 +5651,16 @@ void __init sparse_memory_present_with_a > > unsigned long start_pfn, end_pfn; > > int i, this_nid; > > > > +#ifdef CONFIG_SPARSEMEM_EXTREME > > + if (!mem_section) { > > + unsigned long size, align; > > + > > + size = sizeof(struct mem_section) * NR_SECTION_ROOTS; > > + align = 1 << (INTERNODE_CACHE_SHIFT); > > + mem_section = memblock_virt_alloc(size, align); > > + } > > +#endif > > + > > for_each_mem_pfn_range(i, nid, _pfn, _pfn, _nid) > > memory_present(this_nid, start_pfn, end_pfn); > > } > > --- a/mm/sparse.c > > +++ b/mm/sparse.c > > @@ -23,8 +23,7 @@ > > * 1) mem_section - memory sections, mem_map's for valid memory > > */ > > #ifdef CONFIG_SPARSEMEM_EXTREME > > -struct mem_section *mem_section[NR_SECTION_ROOTS] > > - cacheline_internodealigned_in_smp; > > +struct mem_section **mem_section; > > #else > > struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT] > > cacheline_internodealigned_in_smp; > > @@ -101,7 +100,7 @@ static inline int sparse_index_init(unsi > > int __section_nr(struct mem_section* ms) > > { > > unsigned long root_nr; > > - struct mem_section* root; > > + struct mem_section *root = NULL; > > > > for (root_nr = 0; root_nr < NR_SECTION_ROOTS; root_nr++) { > > root = __nr_to_section(root_nr * SECTIONS_PER_ROOT); > > @@ -112,7 +111,7 @@ int __section_nr(struct mem_section* ms) > > break; > > } > > > > - VM_BUG_ON(root_nr == NR_SECTION_ROOTS); > > + VM_BUG_ON(!root); > > > > return (root_nr * SECTIONS_PER_ROOT) + (ms - root); > > } > > @@ -330,11 +329,17 @@ again: > > static void __init check_usemap_section_nr(int nid, unsigned long *usemap) > > { > > unsigned long usemap_snr, pgdat_snr; > > - static unsigned long old_usemap_snr = NR_MEM_SECTIONS; > > - static unsigned long old_pgdat_snr = NR_MEM_SECTIONS; > > + static unsigned long old_usemap_snr; > > +
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Mon, 2018-01-08 at 09:33 +0100, Greg Kroah-Hartman wrote: > On Mon, Jan 08, 2018 at 09:15:33AM +0100, Mike Galbraith wrote: > > > > It was part of the prep for the KTPI code from what I can tell. If you > > > think it should be reverted, just let me know and I'll be glad to do so. > > > > No preference here. I have to patch master regardless if I want kdump > > to work while I patiently wait for userspace to get fixed up (either > > that or use time I don't have to go fix it up myself). > > I'll stay "bug compatible" for the time being. If you do fix this up, > can you add a cc: stable tag in your patch so I can pick it up when it > gets merged? Userspace (makedumpfile) will have to adapt, not the kernel. Meanwhile I carry reverts, making kernels, kdump and myself all happy campers. -Mike
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Mon, 2018-01-08 at 09:33 +0100, Greg Kroah-Hartman wrote: > On Mon, Jan 08, 2018 at 09:15:33AM +0100, Mike Galbraith wrote: > > > > It was part of the prep for the KTPI code from what I can tell. If you > > > think it should be reverted, just let me know and I'll be glad to do so. > > > > No preference here. I have to patch master regardless if I want kdump > > to work while I patiently wait for userspace to get fixed up (either > > that or use time I don't have to go fix it up myself). > > I'll stay "bug compatible" for the time being. If you do fix this up, > can you add a cc: stable tag in your patch so I can pick it up when it > gets merged? Userspace (makedumpfile) will have to adapt, not the kernel. Meanwhile I carry reverts, making kernels, kdump and myself all happy campers. -Mike
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Mon, Jan 08, 2018 at 10:10:44AM +0100, Greg Kroah-Hartman wrote: > On Mon, Jan 08, 2018 at 09:47:23AM +0100, Michal Hocko wrote: > > On Mon 08-01-18 08:53:08, Greg KH wrote: > > > On Sun, Jan 07, 2018 at 02:23:09PM +0100, Michal Hocko wrote: > > > > On Sun 07-01-18 13:44:02, Mike Galbraith wrote: > > > > > On Sun, 2018-01-07 at 11:18 +0100, Michal Hocko wrote: > > > > > > On Sun 07-01-18 10:11:15, Greg KH wrote: > > > > > > > On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote: > > > > > > > > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote: > > > > > > > > > 4.14-stable review patch. If anyone has any objections, > > > > > > > > > please let me know. > > > > > > > > > > > > > > > > FYI, this broke kdump, or rather the makedumpfile part thereof. > > > > > > > > Forward looking wreckage is par for the kdump course, but... > > > > > > > > > > > > > > Is it also broken in Linus's tree with this patch? Or is there an > > > > > > > add-on patch that I should apply to 4.14 to resolve this issue > > > > > > > there? > > > > > > > > > > > > This one > > > > > > http://lkml.kernel.org/r/1513932498-20350-1-git-send-email-...@redhat.com > > > > > > I guess. > > > > > > > > > > That won't unbreak kdump, else master wouldn't be broken. I don't > > > > > care > > > > > deeply, or know if anyone else does, I'm just reporting it because I > > > > > met it and chased it down. > > > > > > > > OK, I didn't notice that d8cfbbfa0f7 ("mm/sparse.c: wrong allocation > > > > for mem_section") made it in after rc6. I am still wondering why > > > > 83e3c48729 ("mm/sparsemem: Allocate mem_section at runtime for > > > > CONFIG_SPARSEMEM_EXTREME=y") made it into the stable tree in the first > > > > place. > > > > > > It was part of the prep for the KTPI code from what I can tell. > > > > I do not see a direct relation, to be honest. It is more related to > > 5-level page tables but I might be missing some subtle relation. > > > > > If you > > > think it should be reverted, just let me know and I'll be glad to do so. > > > > This seems to be affecting Linus tree as well so it needs to get > > resolved. I would suggest reverting in stable for the mean time. > > If you really need it in the stable tree then you can pull it back later > > with all the follow up fixes. > > Ok, I've now reverted it, thanks. Nope, it breaks the build when reverted, I'm dropping that revert now. It's as if the x86 maintainers actually knew what they were doing in asking for this to be backported :) thanks, greg k-h
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Mon, Jan 08, 2018 at 10:10:44AM +0100, Greg Kroah-Hartman wrote: > On Mon, Jan 08, 2018 at 09:47:23AM +0100, Michal Hocko wrote: > > On Mon 08-01-18 08:53:08, Greg KH wrote: > > > On Sun, Jan 07, 2018 at 02:23:09PM +0100, Michal Hocko wrote: > > > > On Sun 07-01-18 13:44:02, Mike Galbraith wrote: > > > > > On Sun, 2018-01-07 at 11:18 +0100, Michal Hocko wrote: > > > > > > On Sun 07-01-18 10:11:15, Greg KH wrote: > > > > > > > On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote: > > > > > > > > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote: > > > > > > > > > 4.14-stable review patch. If anyone has any objections, > > > > > > > > > please let me know. > > > > > > > > > > > > > > > > FYI, this broke kdump, or rather the makedumpfile part thereof. > > > > > > > > Forward looking wreckage is par for the kdump course, but... > > > > > > > > > > > > > > Is it also broken in Linus's tree with this patch? Or is there an > > > > > > > add-on patch that I should apply to 4.14 to resolve this issue > > > > > > > there? > > > > > > > > > > > > This one > > > > > > http://lkml.kernel.org/r/1513932498-20350-1-git-send-email-...@redhat.com > > > > > > I guess. > > > > > > > > > > That won't unbreak kdump, else master wouldn't be broken. I don't > > > > > care > > > > > deeply, or know if anyone else does, I'm just reporting it because I > > > > > met it and chased it down. > > > > > > > > OK, I didn't notice that d8cfbbfa0f7 ("mm/sparse.c: wrong allocation > > > > for mem_section") made it in after rc6. I am still wondering why > > > > 83e3c48729 ("mm/sparsemem: Allocate mem_section at runtime for > > > > CONFIG_SPARSEMEM_EXTREME=y") made it into the stable tree in the first > > > > place. > > > > > > It was part of the prep for the KTPI code from what I can tell. > > > > I do not see a direct relation, to be honest. It is more related to > > 5-level page tables but I might be missing some subtle relation. > > > > > If you > > > think it should be reverted, just let me know and I'll be glad to do so. > > > > This seems to be affecting Linus tree as well so it needs to get > > resolved. I would suggest reverting in stable for the mean time. > > If you really need it in the stable tree then you can pull it back later > > with all the follow up fixes. > > Ok, I've now reverted it, thanks. Nope, it breaks the build when reverted, I'm dropping that revert now. It's as if the x86 maintainers actually knew what they were doing in asking for this to be backported :) thanks, greg k-h
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Mon, Jan 08, 2018 at 09:47:23AM +0100, Michal Hocko wrote: > On Mon 08-01-18 08:53:08, Greg KH wrote: > > On Sun, Jan 07, 2018 at 02:23:09PM +0100, Michal Hocko wrote: > > > On Sun 07-01-18 13:44:02, Mike Galbraith wrote: > > > > On Sun, 2018-01-07 at 11:18 +0100, Michal Hocko wrote: > > > > > On Sun 07-01-18 10:11:15, Greg KH wrote: > > > > > > On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote: > > > > > > > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote: > > > > > > > > 4.14-stable review patch. If anyone has any objections, please > > > > > > > > let me know. > > > > > > > > > > > > > > FYI, this broke kdump, or rather the makedumpfile part thereof. > > > > > > > Forward looking wreckage is par for the kdump course, but... > > > > > > > > > > > > Is it also broken in Linus's tree with this patch? Or is there an > > > > > > add-on patch that I should apply to 4.14 to resolve this issue > > > > > > there? > > > > > > > > > > This one > > > > > http://lkml.kernel.org/r/1513932498-20350-1-git-send-email-...@redhat.com > > > > > I guess. > > > > > > > > That won't unbreak kdump, else master wouldn't be broken. I don't care > > > > deeply, or know if anyone else does, I'm just reporting it because I > > > > met it and chased it down. > > > > > > OK, I didn't notice that d8cfbbfa0f7 ("mm/sparse.c: wrong allocation > > > for mem_section") made it in after rc6. I am still wondering why > > > 83e3c48729 ("mm/sparsemem: Allocate mem_section at runtime for > > > CONFIG_SPARSEMEM_EXTREME=y") made it into the stable tree in the first > > > place. > > > > It was part of the prep for the KTPI code from what I can tell. > > I do not see a direct relation, to be honest. It is more related to > 5-level page tables but I might be missing some subtle relation. > > > If you > > think it should be reverted, just let me know and I'll be glad to do so. > > This seems to be affecting Linus tree as well so it needs to get > resolved. I would suggest reverting in stable for the mean time. > If you really need it in the stable tree then you can pull it back later > with all the follow up fixes. Ok, I've now reverted it, thanks. greg k-h
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Mon, Jan 08, 2018 at 09:47:23AM +0100, Michal Hocko wrote: > On Mon 08-01-18 08:53:08, Greg KH wrote: > > On Sun, Jan 07, 2018 at 02:23:09PM +0100, Michal Hocko wrote: > > > On Sun 07-01-18 13:44:02, Mike Galbraith wrote: > > > > On Sun, 2018-01-07 at 11:18 +0100, Michal Hocko wrote: > > > > > On Sun 07-01-18 10:11:15, Greg KH wrote: > > > > > > On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote: > > > > > > > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote: > > > > > > > > 4.14-stable review patch. If anyone has any objections, please > > > > > > > > let me know. > > > > > > > > > > > > > > FYI, this broke kdump, or rather the makedumpfile part thereof. > > > > > > > Forward looking wreckage is par for the kdump course, but... > > > > > > > > > > > > Is it also broken in Linus's tree with this patch? Or is there an > > > > > > add-on patch that I should apply to 4.14 to resolve this issue > > > > > > there? > > > > > > > > > > This one > > > > > http://lkml.kernel.org/r/1513932498-20350-1-git-send-email-...@redhat.com > > > > > I guess. > > > > > > > > That won't unbreak kdump, else master wouldn't be broken. I don't care > > > > deeply, or know if anyone else does, I'm just reporting it because I > > > > met it and chased it down. > > > > > > OK, I didn't notice that d8cfbbfa0f7 ("mm/sparse.c: wrong allocation > > > for mem_section") made it in after rc6. I am still wondering why > > > 83e3c48729 ("mm/sparsemem: Allocate mem_section at runtime for > > > CONFIG_SPARSEMEM_EXTREME=y") made it into the stable tree in the first > > > place. > > > > It was part of the prep for the KTPI code from what I can tell. > > I do not see a direct relation, to be honest. It is more related to > 5-level page tables but I might be missing some subtle relation. > > > If you > > think it should be reverted, just let me know and I'll be glad to do so. > > This seems to be affecting Linus tree as well so it needs to get > resolved. I would suggest reverting in stable for the mean time. > If you really need it in the stable tree then you can pull it back later > with all the follow up fixes. Ok, I've now reverted it, thanks. greg k-h
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Mon 08-01-18 08:53:08, Greg KH wrote: > On Sun, Jan 07, 2018 at 02:23:09PM +0100, Michal Hocko wrote: > > On Sun 07-01-18 13:44:02, Mike Galbraith wrote: > > > On Sun, 2018-01-07 at 11:18 +0100, Michal Hocko wrote: > > > > On Sun 07-01-18 10:11:15, Greg KH wrote: > > > > > On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote: > > > > > > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote: > > > > > > > 4.14-stable review patch. If anyone has any objections, please > > > > > > > let me know. > > > > > > > > > > > > FYI, this broke kdump, or rather the makedumpfile part thereof. > > > > > > Forward looking wreckage is par for the kdump course, but... > > > > > > > > > > Is it also broken in Linus's tree with this patch? Or is there an > > > > > add-on patch that I should apply to 4.14 to resolve this issue there? > > > > > > > > This one > > > > http://lkml.kernel.org/r/1513932498-20350-1-git-send-email-...@redhat.com > > > > I guess. > > > > > > That won't unbreak kdump, else master wouldn't be broken. I don't care > > > deeply, or know if anyone else does, I'm just reporting it because I > > > met it and chased it down. > > > > OK, I didn't notice that d8cfbbfa0f7 ("mm/sparse.c: wrong allocation > > for mem_section") made it in after rc6. I am still wondering why > > 83e3c48729 ("mm/sparsemem: Allocate mem_section at runtime for > > CONFIG_SPARSEMEM_EXTREME=y") made it into the stable tree in the first > > place. > > It was part of the prep for the KTPI code from what I can tell. I do not see a direct relation, to be honest. It is more related to 5-level page tables but I might be missing some subtle relation. > If you > think it should be reverted, just let me know and I'll be glad to do so. This seems to be affecting Linus tree as well so it needs to get resolved. I would suggest reverting in stable for the mean time. If you really need it in the stable tree then you can pull it back later with all the follow up fixes. -- Michal Hocko SUSE Labs
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Mon 08-01-18 08:53:08, Greg KH wrote: > On Sun, Jan 07, 2018 at 02:23:09PM +0100, Michal Hocko wrote: > > On Sun 07-01-18 13:44:02, Mike Galbraith wrote: > > > On Sun, 2018-01-07 at 11:18 +0100, Michal Hocko wrote: > > > > On Sun 07-01-18 10:11:15, Greg KH wrote: > > > > > On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote: > > > > > > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote: > > > > > > > 4.14-stable review patch. If anyone has any objections, please > > > > > > > let me know. > > > > > > > > > > > > FYI, this broke kdump, or rather the makedumpfile part thereof. > > > > > > Forward looking wreckage is par for the kdump course, but... > > > > > > > > > > Is it also broken in Linus's tree with this patch? Or is there an > > > > > add-on patch that I should apply to 4.14 to resolve this issue there? > > > > > > > > This one > > > > http://lkml.kernel.org/r/1513932498-20350-1-git-send-email-...@redhat.com > > > > I guess. > > > > > > That won't unbreak kdump, else master wouldn't be broken. I don't care > > > deeply, or know if anyone else does, I'm just reporting it because I > > > met it and chased it down. > > > > OK, I didn't notice that d8cfbbfa0f7 ("mm/sparse.c: wrong allocation > > for mem_section") made it in after rc6. I am still wondering why > > 83e3c48729 ("mm/sparsemem: Allocate mem_section at runtime for > > CONFIG_SPARSEMEM_EXTREME=y") made it into the stable tree in the first > > place. > > It was part of the prep for the KTPI code from what I can tell. I do not see a direct relation, to be honest. It is more related to 5-level page tables but I might be missing some subtle relation. > If you > think it should be reverted, just let me know and I'll be glad to do so. This seems to be affecting Linus tree as well so it needs to get resolved. I would suggest reverting in stable for the mean time. If you really need it in the stable tree then you can pull it back later with all the follow up fixes. -- Michal Hocko SUSE Labs
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Mon, Jan 08, 2018 at 09:15:33AM +0100, Mike Galbraith wrote: > On Mon, 2018-01-08 at 08:53 +0100, Greg Kroah-Hartman wrote: > > On Sun, Jan 07, 2018 at 02:23:09PM +0100, Michal Hocko wrote: > > > On Sun 07-01-18 13:44:02, Mike Galbraith wrote: > > > > On Sun, 2018-01-07 at 11:18 +0100, Michal Hocko wrote: > > > > > On Sun 07-01-18 10:11:15, Greg KH wrote: > > > > > > On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote: > > > > > > > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote: > > > > > > > > 4.14-stable review patch. If anyone has any objections, please > > > > > > > > let me know. > > > > > > > > > > > > > > FYI, this broke kdump, or rather the makedumpfile part thereof. > > > > > > > Forward looking wreckage is par for the kdump course, but... > > > > > > > > > > > > Is it also broken in Linus's tree with this patch? Or is there an > > > > > > add-on patch that I should apply to 4.14 to resolve this issue > > > > > > there? > > > > > > > > > > This one > > > > > http://lkml.kernel.org/r/1513932498-20350-1-git-send-email-...@redhat.com > > > > > I guess. > > > > > > > > That won't unbreak kdump, else master wouldn't be broken. I don't care > > > > deeply, or know if anyone else does, I'm just reporting it because I > > > > met it and chased it down. > > > > > > OK, I didn't notice that d8cfbbfa0f7 ("mm/sparse.c: wrong allocation > > > for mem_section") made it in after rc6. I am still wondering why > > > 83e3c48729 ("mm/sparsemem: Allocate mem_section at runtime for > > > CONFIG_SPARSEMEM_EXTREME=y") made it into the stable tree in the first > > > place. > > > > It was part of the prep for the KTPI code from what I can tell. If you > > think it should be reverted, just let me know and I'll be glad to do so. > > No preference here. I have to patch master regardless if I want kdump > to work while I patiently wait for userspace to get fixed up (either > that or use time I don't have to go fix it up myself). I'll stay "bug compatible" for the time being. If you do fix this up, can you add a cc: stable tag in your patch so I can pick it up when it gets merged? thanks, greg k-h
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Mon, Jan 08, 2018 at 09:15:33AM +0100, Mike Galbraith wrote: > On Mon, 2018-01-08 at 08:53 +0100, Greg Kroah-Hartman wrote: > > On Sun, Jan 07, 2018 at 02:23:09PM +0100, Michal Hocko wrote: > > > On Sun 07-01-18 13:44:02, Mike Galbraith wrote: > > > > On Sun, 2018-01-07 at 11:18 +0100, Michal Hocko wrote: > > > > > On Sun 07-01-18 10:11:15, Greg KH wrote: > > > > > > On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote: > > > > > > > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote: > > > > > > > > 4.14-stable review patch. If anyone has any objections, please > > > > > > > > let me know. > > > > > > > > > > > > > > FYI, this broke kdump, or rather the makedumpfile part thereof. > > > > > > > Forward looking wreckage is par for the kdump course, but... > > > > > > > > > > > > Is it also broken in Linus's tree with this patch? Or is there an > > > > > > add-on patch that I should apply to 4.14 to resolve this issue > > > > > > there? > > > > > > > > > > This one > > > > > http://lkml.kernel.org/r/1513932498-20350-1-git-send-email-...@redhat.com > > > > > I guess. > > > > > > > > That won't unbreak kdump, else master wouldn't be broken. I don't care > > > > deeply, or know if anyone else does, I'm just reporting it because I > > > > met it and chased it down. > > > > > > OK, I didn't notice that d8cfbbfa0f7 ("mm/sparse.c: wrong allocation > > > for mem_section") made it in after rc6. I am still wondering why > > > 83e3c48729 ("mm/sparsemem: Allocate mem_section at runtime for > > > CONFIG_SPARSEMEM_EXTREME=y") made it into the stable tree in the first > > > place. > > > > It was part of the prep for the KTPI code from what I can tell. If you > > think it should be reverted, just let me know and I'll be glad to do so. > > No preference here. I have to patch master regardless if I want kdump > to work while I patiently wait for userspace to get fixed up (either > that or use time I don't have to go fix it up myself). I'll stay "bug compatible" for the time being. If you do fix this up, can you add a cc: stable tag in your patch so I can pick it up when it gets merged? thanks, greg k-h
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Mon, 2018-01-08 at 08:53 +0100, Greg Kroah-Hartman wrote: > On Sun, Jan 07, 2018 at 02:23:09PM +0100, Michal Hocko wrote: > > On Sun 07-01-18 13:44:02, Mike Galbraith wrote: > > > On Sun, 2018-01-07 at 11:18 +0100, Michal Hocko wrote: > > > > On Sun 07-01-18 10:11:15, Greg KH wrote: > > > > > On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote: > > > > > > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote: > > > > > > > 4.14-stable review patch. If anyone has any objections, please > > > > > > > let me know. > > > > > > > > > > > > FYI, this broke kdump, or rather the makedumpfile part thereof. > > > > > > Forward looking wreckage is par for the kdump course, but... > > > > > > > > > > Is it also broken in Linus's tree with this patch? Or is there an > > > > > add-on patch that I should apply to 4.14 to resolve this issue there? > > > > > > > > This one > > > > http://lkml.kernel.org/r/1513932498-20350-1-git-send-email-...@redhat.com > > > > I guess. > > > > > > That won't unbreak kdump, else master wouldn't be broken. I don't care > > > deeply, or know if anyone else does, I'm just reporting it because I > > > met it and chased it down. > > > > OK, I didn't notice that d8cfbbfa0f7 ("mm/sparse.c: wrong allocation > > for mem_section") made it in after rc6. I am still wondering why > > 83e3c48729 ("mm/sparsemem: Allocate mem_section at runtime for > > CONFIG_SPARSEMEM_EXTREME=y") made it into the stable tree in the first > > place. > > It was part of the prep for the KTPI code from what I can tell. If you > think it should be reverted, just let me know and I'll be glad to do so. No preference here. I have to patch master regardless if I want kdump to work while I patiently wait for userspace to get fixed up (either that or use time I don't have to go fix it up myself). -Mike
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Mon, 2018-01-08 at 08:53 +0100, Greg Kroah-Hartman wrote: > On Sun, Jan 07, 2018 at 02:23:09PM +0100, Michal Hocko wrote: > > On Sun 07-01-18 13:44:02, Mike Galbraith wrote: > > > On Sun, 2018-01-07 at 11:18 +0100, Michal Hocko wrote: > > > > On Sun 07-01-18 10:11:15, Greg KH wrote: > > > > > On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote: > > > > > > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote: > > > > > > > 4.14-stable review patch. If anyone has any objections, please > > > > > > > let me know. > > > > > > > > > > > > FYI, this broke kdump, or rather the makedumpfile part thereof. > > > > > > Forward looking wreckage is par for the kdump course, but... > > > > > > > > > > Is it also broken in Linus's tree with this patch? Or is there an > > > > > add-on patch that I should apply to 4.14 to resolve this issue there? > > > > > > > > This one > > > > http://lkml.kernel.org/r/1513932498-20350-1-git-send-email-...@redhat.com > > > > I guess. > > > > > > That won't unbreak kdump, else master wouldn't be broken. I don't care > > > deeply, or know if anyone else does, I'm just reporting it because I > > > met it and chased it down. > > > > OK, I didn't notice that d8cfbbfa0f7 ("mm/sparse.c: wrong allocation > > for mem_section") made it in after rc6. I am still wondering why > > 83e3c48729 ("mm/sparsemem: Allocate mem_section at runtime for > > CONFIG_SPARSEMEM_EXTREME=y") made it into the stable tree in the first > > place. > > It was part of the prep for the KTPI code from what I can tell. If you > think it should be reverted, just let me know and I'll be glad to do so. No preference here. I have to patch master regardless if I want kdump to work while I patiently wait for userspace to get fixed up (either that or use time I don't have to go fix it up myself). -Mike
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Sun, Jan 07, 2018 at 02:23:09PM +0100, Michal Hocko wrote: > On Sun 07-01-18 13:44:02, Mike Galbraith wrote: > > On Sun, 2018-01-07 at 11:18 +0100, Michal Hocko wrote: > > > On Sun 07-01-18 10:11:15, Greg KH wrote: > > > > On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote: > > > > > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote: > > > > > > 4.14-stable review patch. If anyone has any objections, please let > > > > > > me know. > > > > > > > > > > FYI, this broke kdump, or rather the makedumpfile part thereof. > > > > > Forward looking wreckage is par for the kdump course, but... > > > > > > > > Is it also broken in Linus's tree with this patch? Or is there an > > > > add-on patch that I should apply to 4.14 to resolve this issue there? > > > > > > This one > > > http://lkml.kernel.org/r/1513932498-20350-1-git-send-email-...@redhat.com > > > I guess. > > > > That won't unbreak kdump, else master wouldn't be broken. I don't care > > deeply, or know if anyone else does, I'm just reporting it because I > > met it and chased it down. > > OK, I didn't notice that d8cfbbfa0f7 ("mm/sparse.c: wrong allocation > for mem_section") made it in after rc6. I am still wondering why > 83e3c48729 ("mm/sparsemem: Allocate mem_section at runtime for > CONFIG_SPARSEMEM_EXTREME=y") made it into the stable tree in the first > place. It was part of the prep for the KTPI code from what I can tell. If you think it should be reverted, just let me know and I'll be glad to do so. thanks, greg k-h
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Sun, Jan 07, 2018 at 02:23:09PM +0100, Michal Hocko wrote: > On Sun 07-01-18 13:44:02, Mike Galbraith wrote: > > On Sun, 2018-01-07 at 11:18 +0100, Michal Hocko wrote: > > > On Sun 07-01-18 10:11:15, Greg KH wrote: > > > > On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote: > > > > > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote: > > > > > > 4.14-stable review patch. If anyone has any objections, please let > > > > > > me know. > > > > > > > > > > FYI, this broke kdump, or rather the makedumpfile part thereof. > > > > > Forward looking wreckage is par for the kdump course, but... > > > > > > > > Is it also broken in Linus's tree with this patch? Or is there an > > > > add-on patch that I should apply to 4.14 to resolve this issue there? > > > > > > This one > > > http://lkml.kernel.org/r/1513932498-20350-1-git-send-email-...@redhat.com > > > I guess. > > > > That won't unbreak kdump, else master wouldn't be broken. I don't care > > deeply, or know if anyone else does, I'm just reporting it because I > > met it and chased it down. > > OK, I didn't notice that d8cfbbfa0f7 ("mm/sparse.c: wrong allocation > for mem_section") made it in after rc6. I am still wondering why > 83e3c48729 ("mm/sparsemem: Allocate mem_section at runtime for > CONFIG_SPARSEMEM_EXTREME=y") made it into the stable tree in the first > place. It was part of the prep for the KTPI code from what I can tell. If you think it should be reverted, just let me know and I'll be glad to do so. thanks, greg k-h
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Sun 07-01-18 13:44:02, Mike Galbraith wrote: > On Sun, 2018-01-07 at 11:18 +0100, Michal Hocko wrote: > > On Sun 07-01-18 10:11:15, Greg KH wrote: > > > On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote: > > > > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote: > > > > > 4.14-stable review patch. If anyone has any objections, please let > > > > > me know. > > > > > > > > FYI, this broke kdump, or rather the makedumpfile part thereof. > > > > Forward looking wreckage is par for the kdump course, but... > > > > > > Is it also broken in Linus's tree with this patch? Or is there an > > > add-on patch that I should apply to 4.14 to resolve this issue there? > > > > This one > > http://lkml.kernel.org/r/1513932498-20350-1-git-send-email-...@redhat.com > > I guess. > > That won't unbreak kdump, else master wouldn't be broken. I don't care > deeply, or know if anyone else does, I'm just reporting it because I > met it and chased it down. OK, I didn't notice that d8cfbbfa0f7 ("mm/sparse.c: wrong allocation for mem_section") made it in after rc6. I am still wondering why 83e3c48729 ("mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y") made it into the stable tree in the first place. -- Michal Hocko SUSE Labs
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Sun 07-01-18 13:44:02, Mike Galbraith wrote: > On Sun, 2018-01-07 at 11:18 +0100, Michal Hocko wrote: > > On Sun 07-01-18 10:11:15, Greg KH wrote: > > > On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote: > > > > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote: > > > > > 4.14-stable review patch. If anyone has any objections, please let > > > > > me know. > > > > > > > > FYI, this broke kdump, or rather the makedumpfile part thereof. > > > > Forward looking wreckage is par for the kdump course, but... > > > > > > Is it also broken in Linus's tree with this patch? Or is there an > > > add-on patch that I should apply to 4.14 to resolve this issue there? > > > > This one > > http://lkml.kernel.org/r/1513932498-20350-1-git-send-email-...@redhat.com > > I guess. > > That won't unbreak kdump, else master wouldn't be broken. I don't care > deeply, or know if anyone else does, I'm just reporting it because I > met it and chased it down. OK, I didn't notice that d8cfbbfa0f7 ("mm/sparse.c: wrong allocation for mem_section") made it in after rc6. I am still wondering why 83e3c48729 ("mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y") made it into the stable tree in the first place. -- Michal Hocko SUSE Labs
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Sun, 2018-01-07 at 11:18 +0100, Michal Hocko wrote: > On Sun 07-01-18 10:11:15, Greg KH wrote: > > On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote: > > > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote: > > > > 4.14-stable review patch. If anyone has any objections, please let me > > > > know. > > > > > > FYI, this broke kdump, or rather the makedumpfile part thereof. > > > Forward looking wreckage is par for the kdump course, but... > > > > Is it also broken in Linus's tree with this patch? Or is there an > > add-on patch that I should apply to 4.14 to resolve this issue there? > > This one > http://lkml.kernel.org/r/1513932498-20350-1-git-send-email-...@redhat.com > I guess. That won't unbreak kdump, else master wouldn't be broken. I don't care deeply, or know if anyone else does, I'm just reporting it because I met it and chased it down. -Mike
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Sun, 2018-01-07 at 11:18 +0100, Michal Hocko wrote: > On Sun 07-01-18 10:11:15, Greg KH wrote: > > On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote: > > > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote: > > > > 4.14-stable review patch. If anyone has any objections, please let me > > > > know. > > > > > > FYI, this broke kdump, or rather the makedumpfile part thereof. > > > Forward looking wreckage is par for the kdump course, but... > > > > Is it also broken in Linus's tree with this patch? Or is there an > > add-on patch that I should apply to 4.14 to resolve this issue there? > > This one > http://lkml.kernel.org/r/1513932498-20350-1-git-send-email-...@redhat.com > I guess. That won't unbreak kdump, else master wouldn't be broken. I don't care deeply, or know if anyone else does, I'm just reporting it because I met it and chased it down. -Mike
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Sun, Jan 07, 2018 at 11:18:47AM +0100, Michal Hocko wrote: > On Sun 07-01-18 10:11:15, Greg KH wrote: > > On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote: > > > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote: > > > > 4.14-stable review patch. If anyone has any objections, please let me > > > > know. > > > > > > FYI, this broke kdump, or rather the makedumpfile part thereof. > > > Forward looking wreckage is par for the kdump course, but... > > > > Is it also broken in Linus's tree with this patch? Or is there an > > add-on patch that I should apply to 4.14 to resolve this issue there? > > This one > http://lkml.kernel.org/r/1513932498-20350-1-git-send-email-...@redhat.com > I guess. Good, that patch is queued up for the next 4.14-stable release in a few days. thanks, greg k-h
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Sun, Jan 07, 2018 at 11:18:47AM +0100, Michal Hocko wrote: > On Sun 07-01-18 10:11:15, Greg KH wrote: > > On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote: > > > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote: > > > > 4.14-stable review patch. If anyone has any objections, please let me > > > > know. > > > > > > FYI, this broke kdump, or rather the makedumpfile part thereof. > > > Forward looking wreckage is par for the kdump course, but... > > > > Is it also broken in Linus's tree with this patch? Or is there an > > add-on patch that I should apply to 4.14 to resolve this issue there? > > This one > http://lkml.kernel.org/r/1513932498-20350-1-git-send-email-...@redhat.com > I guess. Good, that patch is queued up for the next 4.14-stable release in a few days. thanks, greg k-h
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Sun 07-01-18 10:11:15, Greg KH wrote: > On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote: > > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote: > > > 4.14-stable review patch. If anyone has any objections, please let me > > > know. > > > > FYI, this broke kdump, or rather the makedumpfile part thereof. > > Forward looking wreckage is par for the kdump course, but... > > Is it also broken in Linus's tree with this patch? Or is there an > add-on patch that I should apply to 4.14 to resolve this issue there? This one http://lkml.kernel.org/r/1513932498-20350-1-git-send-email-...@redhat.com I guess. -- Michal Hocko SUSE Labs
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Sun 07-01-18 10:11:15, Greg KH wrote: > On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote: > > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote: > > > 4.14-stable review patch. If anyone has any objections, please let me > > > know. > > > > FYI, this broke kdump, or rather the makedumpfile part thereof. > > Forward looking wreckage is par for the kdump course, but... > > Is it also broken in Linus's tree with this patch? Or is there an > add-on patch that I should apply to 4.14 to resolve this issue there? This one http://lkml.kernel.org/r/1513932498-20350-1-git-send-email-...@redhat.com I guess. -- Michal Hocko SUSE Labs
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Sun, 2018-01-07 at 10:11 +0100, Greg Kroah-Hartman wrote: > On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote: > > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote: > > > 4.14-stable review patch. If anyone has any objections, please let me > > > know. > > > > FYI, this broke kdump, or rather the makedumpfile part thereof. > > Forward looking wreckage is par for the kdump course, but... > > Is it also broken in Linus's tree with this patch? Or is there an > add-on patch that I should apply to 4.14 to resolve this issue there? Yeah, it's belly up. By its very nature, it's gonna get dinged up regularly. I only mentioned it because it's not expected that stuff gets dinged up retroactively. -Mike
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Sun, 2018-01-07 at 10:11 +0100, Greg Kroah-Hartman wrote: > On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote: > > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote: > > > 4.14-stable review patch. If anyone has any objections, please let me > > > know. > > > > FYI, this broke kdump, or rather the makedumpfile part thereof. > > Forward looking wreckage is par for the kdump course, but... > > Is it also broken in Linus's tree with this patch? Or is there an > add-on patch that I should apply to 4.14 to resolve this issue there? Yeah, it's belly up. By its very nature, it's gonna get dinged up regularly. I only mentioned it because it's not expected that stuff gets dinged up retroactively. -Mike
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote: > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote: > > 4.14-stable review patch. If anyone has any objections, please let me know. > > FYI, this broke kdump, or rather the makedumpfile part thereof. > Forward looking wreckage is par for the kdump course, but... Is it also broken in Linus's tree with this patch? Or is there an add-on patch that I should apply to 4.14 to resolve this issue there? thanks, greg k-h
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote: > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote: > > 4.14-stable review patch. If anyone has any objections, please let me know. > > FYI, this broke kdump, or rather the makedumpfile part thereof. > Forward looking wreckage is par for the kdump course, but... Is it also broken in Linus's tree with this patch? Or is there an add-on patch that I should apply to 4.14 to resolve this issue there? thanks, greg k-h
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote: > 4.14-stable review patch. If anyone has any objections, please let me know. FYI, this broke kdump, or rather the makedumpfile part thereof. Forward looking wreckage is par for the kdump course, but... > -- > > From: Kirill A. Shutemov> > commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 upstream. > > Size of the mem_section[] array depends on the size of the physical address > space. > > In preparation for boot-time switching between paging modes on x86-64 > we need to make the allocation of mem_section[] dynamic, because otherwise > we waste a lot of RAM: with CONFIG_NODE_SHIFT=10, mem_section[] size is 32kB > for 4-level paging and 2MB for 5-level paging mode. > > The patch allocates the array on the first call to > sparse_memory_present_with_active_regions(). > > Signed-off-by: Kirill A. Shutemov > Cc: Andrew Morton > Cc: Andy Lutomirski > Cc: Borislav Petkov > Cc: Cyrill Gorcunov > Cc: Linus Torvalds > Cc: Peter Zijlstra > Cc: Thomas Gleixner > Cc: linux...@kvack.org > Link: > http://lkml.kernel.org/r/20170929140821.37654-2-kirill.shute...@linux.intel.com > Signed-off-by: Ingo Molnar > Signed-off-by: Greg Kroah-Hartman > > --- > include/linux/mmzone.h |6 +- > mm/page_alloc.c| 10 ++ > mm/sparse.c| 17 +++-- > 3 files changed, 26 insertions(+), 7 deletions(-) > > --- a/include/linux/mmzone.h > +++ b/include/linux/mmzone.h > @@ -1152,13 +1152,17 @@ struct mem_section { > #define SECTION_ROOT_MASK(SECTIONS_PER_ROOT - 1) > > #ifdef CONFIG_SPARSEMEM_EXTREME > -extern struct mem_section *mem_section[NR_SECTION_ROOTS]; > +extern struct mem_section **mem_section; > #else > extern struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT]; > #endif > > static inline struct mem_section *__nr_to_section(unsigned long nr) > { > +#ifdef CONFIG_SPARSEMEM_EXTREME > + if (!mem_section) > + return NULL; > +#endif > if (!mem_section[SECTION_NR_TO_ROOT(nr)]) > return NULL; > return _section[SECTION_NR_TO_ROOT(nr)][nr & SECTION_ROOT_MASK]; > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -5651,6 +5651,16 @@ void __init sparse_memory_present_with_a > unsigned long start_pfn, end_pfn; > int i, this_nid; > > +#ifdef CONFIG_SPARSEMEM_EXTREME > + if (!mem_section) { > + unsigned long size, align; > + > + size = sizeof(struct mem_section) * NR_SECTION_ROOTS; > + align = 1 << (INTERNODE_CACHE_SHIFT); > + mem_section = memblock_virt_alloc(size, align); > + } > +#endif > + > for_each_mem_pfn_range(i, nid, _pfn, _pfn, _nid) > memory_present(this_nid, start_pfn, end_pfn); > } > --- a/mm/sparse.c > +++ b/mm/sparse.c > @@ -23,8 +23,7 @@ > * 1) mem_section- memory sections, mem_map's for valid memory > */ > #ifdef CONFIG_SPARSEMEM_EXTREME > -struct mem_section *mem_section[NR_SECTION_ROOTS] > - cacheline_internodealigned_in_smp; > +struct mem_section **mem_section; > #else > struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT] > cacheline_internodealigned_in_smp; > @@ -101,7 +100,7 @@ static inline int sparse_index_init(unsi > int __section_nr(struct mem_section* ms) > { > unsigned long root_nr; > - struct mem_section* root; > + struct mem_section *root = NULL; > > for (root_nr = 0; root_nr < NR_SECTION_ROOTS; root_nr++) { > root = __nr_to_section(root_nr * SECTIONS_PER_ROOT); > @@ -112,7 +111,7 @@ int __section_nr(struct mem_section* ms) >break; > } > > - VM_BUG_ON(root_nr == NR_SECTION_ROOTS); > + VM_BUG_ON(!root); > > return (root_nr * SECTIONS_PER_ROOT) + (ms - root); > } > @@ -330,11 +329,17 @@ again: > static void __init check_usemap_section_nr(int nid, unsigned long *usemap) > { > unsigned long usemap_snr, pgdat_snr; > - static unsigned long old_usemap_snr = NR_MEM_SECTIONS; > - static unsigned long old_pgdat_snr = NR_MEM_SECTIONS; > + static unsigned long old_usemap_snr; > + static unsigned long old_pgdat_snr; > struct pglist_data *pgdat = NODE_DATA(nid); > int usemap_nid; > > + /* First call */ > + if (!old_usemap_snr) { > + old_usemap_snr = NR_MEM_SECTIONS; > + old_pgdat_snr = NR_MEM_SECTIONS; > + } > + > usemap_snr = pfn_to_section_nr(__pa(usemap) >> PAGE_SHIFT); > pgdat_snr = pfn_to_section_nr(__pa(pgdat) >> PAGE_SHIFT); > if (usemap_snr == pgdat_snr) > >
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote: > 4.14-stable review patch. If anyone has any objections, please let me know. FYI, this broke kdump, or rather the makedumpfile part thereof. Forward looking wreckage is par for the kdump course, but... > -- > > From: Kirill A. Shutemov > > commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 upstream. > > Size of the mem_section[] array depends on the size of the physical address > space. > > In preparation for boot-time switching between paging modes on x86-64 > we need to make the allocation of mem_section[] dynamic, because otherwise > we waste a lot of RAM: with CONFIG_NODE_SHIFT=10, mem_section[] size is 32kB > for 4-level paging and 2MB for 5-level paging mode. > > The patch allocates the array on the first call to > sparse_memory_present_with_active_regions(). > > Signed-off-by: Kirill A. Shutemov > Cc: Andrew Morton > Cc: Andy Lutomirski > Cc: Borislav Petkov > Cc: Cyrill Gorcunov > Cc: Linus Torvalds > Cc: Peter Zijlstra > Cc: Thomas Gleixner > Cc: linux...@kvack.org > Link: > http://lkml.kernel.org/r/20170929140821.37654-2-kirill.shute...@linux.intel.com > Signed-off-by: Ingo Molnar > Signed-off-by: Greg Kroah-Hartman > > --- > include/linux/mmzone.h |6 +- > mm/page_alloc.c| 10 ++ > mm/sparse.c| 17 +++-- > 3 files changed, 26 insertions(+), 7 deletions(-) > > --- a/include/linux/mmzone.h > +++ b/include/linux/mmzone.h > @@ -1152,13 +1152,17 @@ struct mem_section { > #define SECTION_ROOT_MASK(SECTIONS_PER_ROOT - 1) > > #ifdef CONFIG_SPARSEMEM_EXTREME > -extern struct mem_section *mem_section[NR_SECTION_ROOTS]; > +extern struct mem_section **mem_section; > #else > extern struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT]; > #endif > > static inline struct mem_section *__nr_to_section(unsigned long nr) > { > +#ifdef CONFIG_SPARSEMEM_EXTREME > + if (!mem_section) > + return NULL; > +#endif > if (!mem_section[SECTION_NR_TO_ROOT(nr)]) > return NULL; > return _section[SECTION_NR_TO_ROOT(nr)][nr & SECTION_ROOT_MASK]; > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -5651,6 +5651,16 @@ void __init sparse_memory_present_with_a > unsigned long start_pfn, end_pfn; > int i, this_nid; > > +#ifdef CONFIG_SPARSEMEM_EXTREME > + if (!mem_section) { > + unsigned long size, align; > + > + size = sizeof(struct mem_section) * NR_SECTION_ROOTS; > + align = 1 << (INTERNODE_CACHE_SHIFT); > + mem_section = memblock_virt_alloc(size, align); > + } > +#endif > + > for_each_mem_pfn_range(i, nid, _pfn, _pfn, _nid) > memory_present(this_nid, start_pfn, end_pfn); > } > --- a/mm/sparse.c > +++ b/mm/sparse.c > @@ -23,8 +23,7 @@ > * 1) mem_section- memory sections, mem_map's for valid memory > */ > #ifdef CONFIG_SPARSEMEM_EXTREME > -struct mem_section *mem_section[NR_SECTION_ROOTS] > - cacheline_internodealigned_in_smp; > +struct mem_section **mem_section; > #else > struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT] > cacheline_internodealigned_in_smp; > @@ -101,7 +100,7 @@ static inline int sparse_index_init(unsi > int __section_nr(struct mem_section* ms) > { > unsigned long root_nr; > - struct mem_section* root; > + struct mem_section *root = NULL; > > for (root_nr = 0; root_nr < NR_SECTION_ROOTS; root_nr++) { > root = __nr_to_section(root_nr * SECTIONS_PER_ROOT); > @@ -112,7 +111,7 @@ int __section_nr(struct mem_section* ms) >break; > } > > - VM_BUG_ON(root_nr == NR_SECTION_ROOTS); > + VM_BUG_ON(!root); > > return (root_nr * SECTIONS_PER_ROOT) + (ms - root); > } > @@ -330,11 +329,17 @@ again: > static void __init check_usemap_section_nr(int nid, unsigned long *usemap) > { > unsigned long usemap_snr, pgdat_snr; > - static unsigned long old_usemap_snr = NR_MEM_SECTIONS; > - static unsigned long old_pgdat_snr = NR_MEM_SECTIONS; > + static unsigned long old_usemap_snr; > + static unsigned long old_pgdat_snr; > struct pglist_data *pgdat = NODE_DATA(nid); > int usemap_nid; > > + /* First call */ > + if (!old_usemap_snr) { > + old_usemap_snr = NR_MEM_SECTIONS; > + old_pgdat_snr = NR_MEM_SECTIONS; > + } > + > usemap_snr = pfn_to_section_nr(__pa(usemap) >> PAGE_SHIFT); > pgdat_snr = pfn_to_section_nr(__pa(pgdat) >> PAGE_SHIFT); > if (usemap_snr == pgdat_snr) > >
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Fri, Dec 22, 2017 at 08:22:09PM +0530, Naresh Kamboju wrote: > On 22 December 2017 at 19:48, Dan Ruewrote: > > On Fri, Dec 22, 2017 at 09:45:08AM +0100, Greg Kroah-Hartman wrote: > >> 4.14-stable review patch. If anyone has any objections, please let me > >> know. > >> > >> -- > >> > >> From: Kirill A. Shutemov > >> > >> commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 upstream. > >> > >> Size of the mem_section[] array depends on the size of the physical > >> address space. > >> > >> In preparation for boot-time switching between paging modes on x86-64 > >> we need to make the allocation of mem_section[] dynamic, because otherwise > >> we waste a lot of RAM: with CONFIG_NODE_SHIFT=10, mem_section[] size is > >> 32kB > >> for 4-level paging and 2MB for 5-level paging mode. > >> > >> The patch allocates the array on the first call to > >> sparse_memory_present_with_active_regions(). > >> > >> Signed-off-by: Kirill A. Shutemov > >> Cc: Andrew Morton > >> Cc: Andy Lutomirski > >> Cc: Borislav Petkov > >> Cc: Cyrill Gorcunov > >> Cc: Linus Torvalds > >> Cc: Peter Zijlstra > >> Cc: Thomas Gleixner > >> Cc: linux...@kvack.org > >> Link: > >> http://lkml.kernel.org/r/20170929140821.37654-2-kirill.shute...@linux.intel.com > >> Signed-off-by: Ingo Molnar > >> Signed-off-by: Greg Kroah-Hartman > > > > This patch causes a boot failure on arm64. > > > > Please drop this patch, or pick up the fix in: > > > > commit 629a359bdb0e0652a8227b4ff3125431995fec6e > > Author: Kirill A. Shutemov > > Date: Tue Nov 7 11:33:37 2017 +0300 > > > > mm/sparsemem: Fix ARM64 boot crash when CONFIG_SPARSEMEM_EXTREME=y > > > > See > > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1527427.html > > +1. > Boot failed on arm64 without 629a359b > mm/sparsemem: Fix ARM64 boot crash when CONFIG_SPARSEMEM_EXTREME=y > > Boot Error log: > > [0.00] Unable to handle kernel NULL pointer dereference at > virtual address > [0.00] Mem abort info: > [0.00] Exception class = DABT (current EL), IL = 32 bits > [0.00] SET = 0, FnV = 0 > [0.00] EA = 0, S1PTW = 0 > [0.00] Data abort info: > [0.00] ISV = 0, ISS = 0x0004 > [0.00] CM = 0, WnR = 0 > [0.00] [] user address but active_mm is swapper > [0.00] Internal error: Oops: 9604 [#1] PREEMPT SMP > [0.00] Modules linked in: > [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.14.9-rc1 #1 > [0.00] Hardware name: ARM Juno development board (r2) (DT) > [0.00] task: 091d9380 task.stack: 091c > [0.00] PC is at memory_present+0x64/0xf4 > [0.00] LR is at memory_present+0x38/0xf4 > [0.00] pc : [] lr : [] > pstate: 80c5 > [0.00] sp : 091c3e80 > > More information, > https://pastebin.com/KambxUwb -rc2 is out with the fix, hopefully that survives longer :) thanks, greg k-h
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Fri, Dec 22, 2017 at 08:22:09PM +0530, Naresh Kamboju wrote: > On 22 December 2017 at 19:48, Dan Rue wrote: > > On Fri, Dec 22, 2017 at 09:45:08AM +0100, Greg Kroah-Hartman wrote: > >> 4.14-stable review patch. If anyone has any objections, please let me > >> know. > >> > >> -- > >> > >> From: Kirill A. Shutemov > >> > >> commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 upstream. > >> > >> Size of the mem_section[] array depends on the size of the physical > >> address space. > >> > >> In preparation for boot-time switching between paging modes on x86-64 > >> we need to make the allocation of mem_section[] dynamic, because otherwise > >> we waste a lot of RAM: with CONFIG_NODE_SHIFT=10, mem_section[] size is > >> 32kB > >> for 4-level paging and 2MB for 5-level paging mode. > >> > >> The patch allocates the array on the first call to > >> sparse_memory_present_with_active_regions(). > >> > >> Signed-off-by: Kirill A. Shutemov > >> Cc: Andrew Morton > >> Cc: Andy Lutomirski > >> Cc: Borislav Petkov > >> Cc: Cyrill Gorcunov > >> Cc: Linus Torvalds > >> Cc: Peter Zijlstra > >> Cc: Thomas Gleixner > >> Cc: linux...@kvack.org > >> Link: > >> http://lkml.kernel.org/r/20170929140821.37654-2-kirill.shute...@linux.intel.com > >> Signed-off-by: Ingo Molnar > >> Signed-off-by: Greg Kroah-Hartman > > > > This patch causes a boot failure on arm64. > > > > Please drop this patch, or pick up the fix in: > > > > commit 629a359bdb0e0652a8227b4ff3125431995fec6e > > Author: Kirill A. Shutemov > > Date: Tue Nov 7 11:33:37 2017 +0300 > > > > mm/sparsemem: Fix ARM64 boot crash when CONFIG_SPARSEMEM_EXTREME=y > > > > See > > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1527427.html > > +1. > Boot failed on arm64 without 629a359b > mm/sparsemem: Fix ARM64 boot crash when CONFIG_SPARSEMEM_EXTREME=y > > Boot Error log: > > [0.00] Unable to handle kernel NULL pointer dereference at > virtual address > [0.00] Mem abort info: > [0.00] Exception class = DABT (current EL), IL = 32 bits > [0.00] SET = 0, FnV = 0 > [0.00] EA = 0, S1PTW = 0 > [0.00] Data abort info: > [0.00] ISV = 0, ISS = 0x0004 > [0.00] CM = 0, WnR = 0 > [0.00] [] user address but active_mm is swapper > [0.00] Internal error: Oops: 9604 [#1] PREEMPT SMP > [0.00] Modules linked in: > [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.14.9-rc1 #1 > [0.00] Hardware name: ARM Juno development board (r2) (DT) > [0.00] task: 091d9380 task.stack: 091c > [0.00] PC is at memory_present+0x64/0xf4 > [0.00] LR is at memory_present+0x38/0xf4 > [0.00] pc : [] lr : [] > pstate: 80c5 > [0.00] sp : 091c3e80 > > More information, > https://pastebin.com/KambxUwb -rc2 is out with the fix, hopefully that survives longer :) thanks, greg k-h
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Fri, Dec 22, 2017 at 08:18:10AM -0600, Dan Rue wrote: > On Fri, Dec 22, 2017 at 09:45:08AM +0100, Greg Kroah-Hartman wrote: > > 4.14-stable review patch. If anyone has any objections, please let me know. > > > > -- > > > > From: Kirill A. Shutemov> > > > commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 upstream. > > > > Size of the mem_section[] array depends on the size of the physical address > > space. > > > > In preparation for boot-time switching between paging modes on x86-64 > > we need to make the allocation of mem_section[] dynamic, because otherwise > > we waste a lot of RAM: with CONFIG_NODE_SHIFT=10, mem_section[] size is 32kB > > for 4-level paging and 2MB for 5-level paging mode. > > > > The patch allocates the array on the first call to > > sparse_memory_present_with_active_regions(). > > > > Signed-off-by: Kirill A. Shutemov > > Cc: Andrew Morton > > Cc: Andy Lutomirski > > Cc: Borislav Petkov > > Cc: Cyrill Gorcunov > > Cc: Linus Torvalds > > Cc: Peter Zijlstra > > Cc: Thomas Gleixner > > Cc: linux...@kvack.org > > Link: > > http://lkml.kernel.org/r/20170929140821.37654-2-kirill.shute...@linux.intel.com > > Signed-off-by: Ingo Molnar > > Signed-off-by: Greg Kroah-Hartman > > This patch causes a boot failure on arm64. > > Please drop this patch, or pick up the fix in: > > commit 629a359bdb0e0652a8227b4ff3125431995fec6e > Author: Kirill A. Shutemov > Date: Tue Nov 7 11:33:37 2017 +0300 > > mm/sparsemem: Fix ARM64 boot crash when CONFIG_SPARSEMEM_EXTREME=y > > See https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1527427.html Now added, thanks. greg k-h
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Fri, Dec 22, 2017 at 08:18:10AM -0600, Dan Rue wrote: > On Fri, Dec 22, 2017 at 09:45:08AM +0100, Greg Kroah-Hartman wrote: > > 4.14-stable review patch. If anyone has any objections, please let me know. > > > > -- > > > > From: Kirill A. Shutemov > > > > commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 upstream. > > > > Size of the mem_section[] array depends on the size of the physical address > > space. > > > > In preparation for boot-time switching between paging modes on x86-64 > > we need to make the allocation of mem_section[] dynamic, because otherwise > > we waste a lot of RAM: with CONFIG_NODE_SHIFT=10, mem_section[] size is 32kB > > for 4-level paging and 2MB for 5-level paging mode. > > > > The patch allocates the array on the first call to > > sparse_memory_present_with_active_regions(). > > > > Signed-off-by: Kirill A. Shutemov > > Cc: Andrew Morton > > Cc: Andy Lutomirski > > Cc: Borislav Petkov > > Cc: Cyrill Gorcunov > > Cc: Linus Torvalds > > Cc: Peter Zijlstra > > Cc: Thomas Gleixner > > Cc: linux...@kvack.org > > Link: > > http://lkml.kernel.org/r/20170929140821.37654-2-kirill.shute...@linux.intel.com > > Signed-off-by: Ingo Molnar > > Signed-off-by: Greg Kroah-Hartman > > This patch causes a boot failure on arm64. > > Please drop this patch, or pick up the fix in: > > commit 629a359bdb0e0652a8227b4ff3125431995fec6e > Author: Kirill A. Shutemov > Date: Tue Nov 7 11:33:37 2017 +0300 > > mm/sparsemem: Fix ARM64 boot crash when CONFIG_SPARSEMEM_EXTREME=y > > See https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1527427.html Now added, thanks. greg k-h
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On 22 December 2017 at 19:48, Dan Ruewrote: > On Fri, Dec 22, 2017 at 09:45:08AM +0100, Greg Kroah-Hartman wrote: >> 4.14-stable review patch. If anyone has any objections, please let me know. >> >> -- >> >> From: Kirill A. Shutemov >> >> commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 upstream. >> >> Size of the mem_section[] array depends on the size of the physical address >> space. >> >> In preparation for boot-time switching between paging modes on x86-64 >> we need to make the allocation of mem_section[] dynamic, because otherwise >> we waste a lot of RAM: with CONFIG_NODE_SHIFT=10, mem_section[] size is 32kB >> for 4-level paging and 2MB for 5-level paging mode. >> >> The patch allocates the array on the first call to >> sparse_memory_present_with_active_regions(). >> >> Signed-off-by: Kirill A. Shutemov >> Cc: Andrew Morton >> Cc: Andy Lutomirski >> Cc: Borislav Petkov >> Cc: Cyrill Gorcunov >> Cc: Linus Torvalds >> Cc: Peter Zijlstra >> Cc: Thomas Gleixner >> Cc: linux...@kvack.org >> Link: >> http://lkml.kernel.org/r/20170929140821.37654-2-kirill.shute...@linux.intel.com >> Signed-off-by: Ingo Molnar >> Signed-off-by: Greg Kroah-Hartman > > This patch causes a boot failure on arm64. > > Please drop this patch, or pick up the fix in: > > commit 629a359bdb0e0652a8227b4ff3125431995fec6e > Author: Kirill A. Shutemov > Date: Tue Nov 7 11:33:37 2017 +0300 > > mm/sparsemem: Fix ARM64 boot crash when CONFIG_SPARSEMEM_EXTREME=y > > See https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1527427.html +1. Boot failed on arm64 without 629a359b mm/sparsemem: Fix ARM64 boot crash when CONFIG_SPARSEMEM_EXTREME=y Boot Error log: [0.00] Unable to handle kernel NULL pointer dereference at virtual address [0.00] Mem abort info: [0.00] Exception class = DABT (current EL), IL = 32 bits [0.00] SET = 0, FnV = 0 [0.00] EA = 0, S1PTW = 0 [0.00] Data abort info: [0.00] ISV = 0, ISS = 0x0004 [0.00] CM = 0, WnR = 0 [0.00] [] user address but active_mm is swapper [0.00] Internal error: Oops: 9604 [#1] PREEMPT SMP [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.14.9-rc1 #1 [0.00] Hardware name: ARM Juno development board (r2) (DT) [0.00] task: 091d9380 task.stack: 091c [0.00] PC is at memory_present+0x64/0xf4 [0.00] LR is at memory_present+0x38/0xf4 [0.00] pc : [] lr : [] pstate: 80c5 [0.00] sp : 091c3e80 More information, https://pastebin.com/KambxUwb - Naresh > >> >> --- >> include/linux/mmzone.h |6 +- >> mm/page_alloc.c| 10 ++ >> mm/sparse.c| 17 +++-- >> 3 files changed, 26 insertions(+), 7 deletions(-) >> >> --- a/include/linux/mmzone.h >> +++ b/include/linux/mmzone.h >> @@ -1152,13 +1152,17 @@ struct mem_section { >> #define SECTION_ROOT_MASK(SECTIONS_PER_ROOT - 1) >> >> #ifdef CONFIG_SPARSEMEM_EXTREME >> -extern struct mem_section *mem_section[NR_SECTION_ROOTS]; >> +extern struct mem_section **mem_section; >> #else >> extern struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT]; >> #endif >> >> static inline struct mem_section *__nr_to_section(unsigned long nr) >> { >> +#ifdef CONFIG_SPARSEMEM_EXTREME >> + if (!mem_section) >> + return NULL; >> +#endif >> if (!mem_section[SECTION_NR_TO_ROOT(nr)]) >> return NULL; >> return _section[SECTION_NR_TO_ROOT(nr)][nr & SECTION_ROOT_MASK]; >> --- a/mm/page_alloc.c >> +++ b/mm/page_alloc.c >> @@ -5651,6 +5651,16 @@ void __init sparse_memory_present_with_a >> unsigned long start_pfn, end_pfn; >> int i, this_nid; >> >> +#ifdef CONFIG_SPARSEMEM_EXTREME >> + if (!mem_section) { >> + unsigned long size, align; >> + >> + size = sizeof(struct mem_section) * NR_SECTION_ROOTS; >> + align = 1 << (INTERNODE_CACHE_SHIFT); >> + mem_section = memblock_virt_alloc(size, align); >> + } >> +#endif >> + >> for_each_mem_pfn_range(i, nid, _pfn, _pfn, _nid) >> memory_present(this_nid, start_pfn, end_pfn); >> } >> --- a/mm/sparse.c >> +++ b/mm/sparse.c >> @@ -23,8 +23,7 @@ >> * 1) mem_section- memory sections, mem_map's for valid memory >> */ >> #ifdef CONFIG_SPARSEMEM_EXTREME >> -struct mem_section *mem_section[NR_SECTION_ROOTS] >> - cacheline_internodealigned_in_smp; >> +struct mem_section **mem_section; >> #else >> struct
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On 22 December 2017 at 19:48, Dan Rue wrote: > On Fri, Dec 22, 2017 at 09:45:08AM +0100, Greg Kroah-Hartman wrote: >> 4.14-stable review patch. If anyone has any objections, please let me know. >> >> -- >> >> From: Kirill A. Shutemov >> >> commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 upstream. >> >> Size of the mem_section[] array depends on the size of the physical address >> space. >> >> In preparation for boot-time switching between paging modes on x86-64 >> we need to make the allocation of mem_section[] dynamic, because otherwise >> we waste a lot of RAM: with CONFIG_NODE_SHIFT=10, mem_section[] size is 32kB >> for 4-level paging and 2MB for 5-level paging mode. >> >> The patch allocates the array on the first call to >> sparse_memory_present_with_active_regions(). >> >> Signed-off-by: Kirill A. Shutemov >> Cc: Andrew Morton >> Cc: Andy Lutomirski >> Cc: Borislav Petkov >> Cc: Cyrill Gorcunov >> Cc: Linus Torvalds >> Cc: Peter Zijlstra >> Cc: Thomas Gleixner >> Cc: linux...@kvack.org >> Link: >> http://lkml.kernel.org/r/20170929140821.37654-2-kirill.shute...@linux.intel.com >> Signed-off-by: Ingo Molnar >> Signed-off-by: Greg Kroah-Hartman > > This patch causes a boot failure on arm64. > > Please drop this patch, or pick up the fix in: > > commit 629a359bdb0e0652a8227b4ff3125431995fec6e > Author: Kirill A. Shutemov > Date: Tue Nov 7 11:33:37 2017 +0300 > > mm/sparsemem: Fix ARM64 boot crash when CONFIG_SPARSEMEM_EXTREME=y > > See https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1527427.html +1. Boot failed on arm64 without 629a359b mm/sparsemem: Fix ARM64 boot crash when CONFIG_SPARSEMEM_EXTREME=y Boot Error log: [0.00] Unable to handle kernel NULL pointer dereference at virtual address [0.00] Mem abort info: [0.00] Exception class = DABT (current EL), IL = 32 bits [0.00] SET = 0, FnV = 0 [0.00] EA = 0, S1PTW = 0 [0.00] Data abort info: [0.00] ISV = 0, ISS = 0x0004 [0.00] CM = 0, WnR = 0 [0.00] [] user address but active_mm is swapper [0.00] Internal error: Oops: 9604 [#1] PREEMPT SMP [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.14.9-rc1 #1 [0.00] Hardware name: ARM Juno development board (r2) (DT) [0.00] task: 091d9380 task.stack: 091c [0.00] PC is at memory_present+0x64/0xf4 [0.00] LR is at memory_present+0x38/0xf4 [0.00] pc : [] lr : [] pstate: 80c5 [0.00] sp : 091c3e80 More information, https://pastebin.com/KambxUwb - Naresh > >> >> --- >> include/linux/mmzone.h |6 +- >> mm/page_alloc.c| 10 ++ >> mm/sparse.c| 17 +++-- >> 3 files changed, 26 insertions(+), 7 deletions(-) >> >> --- a/include/linux/mmzone.h >> +++ b/include/linux/mmzone.h >> @@ -1152,13 +1152,17 @@ struct mem_section { >> #define SECTION_ROOT_MASK(SECTIONS_PER_ROOT - 1) >> >> #ifdef CONFIG_SPARSEMEM_EXTREME >> -extern struct mem_section *mem_section[NR_SECTION_ROOTS]; >> +extern struct mem_section **mem_section; >> #else >> extern struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT]; >> #endif >> >> static inline struct mem_section *__nr_to_section(unsigned long nr) >> { >> +#ifdef CONFIG_SPARSEMEM_EXTREME >> + if (!mem_section) >> + return NULL; >> +#endif >> if (!mem_section[SECTION_NR_TO_ROOT(nr)]) >> return NULL; >> return _section[SECTION_NR_TO_ROOT(nr)][nr & SECTION_ROOT_MASK]; >> --- a/mm/page_alloc.c >> +++ b/mm/page_alloc.c >> @@ -5651,6 +5651,16 @@ void __init sparse_memory_present_with_a >> unsigned long start_pfn, end_pfn; >> int i, this_nid; >> >> +#ifdef CONFIG_SPARSEMEM_EXTREME >> + if (!mem_section) { >> + unsigned long size, align; >> + >> + size = sizeof(struct mem_section) * NR_SECTION_ROOTS; >> + align = 1 << (INTERNODE_CACHE_SHIFT); >> + mem_section = memblock_virt_alloc(size, align); >> + } >> +#endif >> + >> for_each_mem_pfn_range(i, nid, _pfn, _pfn, _nid) >> memory_present(this_nid, start_pfn, end_pfn); >> } >> --- a/mm/sparse.c >> +++ b/mm/sparse.c >> @@ -23,8 +23,7 @@ >> * 1) mem_section- memory sections, mem_map's for valid memory >> */ >> #ifdef CONFIG_SPARSEMEM_EXTREME >> -struct mem_section *mem_section[NR_SECTION_ROOTS] >> - cacheline_internodealigned_in_smp; >> +struct mem_section **mem_section; >> #else >> struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT] >> cacheline_internodealigned_in_smp; >> @@ -101,7 +100,7 @@ static inline int sparse_index_init(unsi >> int __section_nr(struct mem_section* ms) >> { >> unsigned long root_nr; >> - struct mem_section* root; >> + struct mem_section *root =
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Fri, Dec 22, 2017 at 09:45:08AM +0100, Greg Kroah-Hartman wrote: > 4.14-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Kirill A. Shutemov> > commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 upstream. > > Size of the mem_section[] array depends on the size of the physical address > space. > > In preparation for boot-time switching between paging modes on x86-64 > we need to make the allocation of mem_section[] dynamic, because otherwise > we waste a lot of RAM: with CONFIG_NODE_SHIFT=10, mem_section[] size is 32kB > for 4-level paging and 2MB for 5-level paging mode. > > The patch allocates the array on the first call to > sparse_memory_present_with_active_regions(). > > Signed-off-by: Kirill A. Shutemov > Cc: Andrew Morton > Cc: Andy Lutomirski > Cc: Borislav Petkov > Cc: Cyrill Gorcunov > Cc: Linus Torvalds > Cc: Peter Zijlstra > Cc: Thomas Gleixner > Cc: linux...@kvack.org > Link: > http://lkml.kernel.org/r/20170929140821.37654-2-kirill.shute...@linux.intel.com > Signed-off-by: Ingo Molnar > Signed-off-by: Greg Kroah-Hartman This patch causes a boot failure on arm64. Please drop this patch, or pick up the fix in: commit 629a359bdb0e0652a8227b4ff3125431995fec6e Author: Kirill A. Shutemov Date: Tue Nov 7 11:33:37 2017 +0300 mm/sparsemem: Fix ARM64 boot crash when CONFIG_SPARSEMEM_EXTREME=y See https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1527427.html > > --- > include/linux/mmzone.h |6 +- > mm/page_alloc.c| 10 ++ > mm/sparse.c| 17 +++-- > 3 files changed, 26 insertions(+), 7 deletions(-) > > --- a/include/linux/mmzone.h > +++ b/include/linux/mmzone.h > @@ -1152,13 +1152,17 @@ struct mem_section { > #define SECTION_ROOT_MASK(SECTIONS_PER_ROOT - 1) > > #ifdef CONFIG_SPARSEMEM_EXTREME > -extern struct mem_section *mem_section[NR_SECTION_ROOTS]; > +extern struct mem_section **mem_section; > #else > extern struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT]; > #endif > > static inline struct mem_section *__nr_to_section(unsigned long nr) > { > +#ifdef CONFIG_SPARSEMEM_EXTREME > + if (!mem_section) > + return NULL; > +#endif > if (!mem_section[SECTION_NR_TO_ROOT(nr)]) > return NULL; > return _section[SECTION_NR_TO_ROOT(nr)][nr & SECTION_ROOT_MASK]; > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -5651,6 +5651,16 @@ void __init sparse_memory_present_with_a > unsigned long start_pfn, end_pfn; > int i, this_nid; > > +#ifdef CONFIG_SPARSEMEM_EXTREME > + if (!mem_section) { > + unsigned long size, align; > + > + size = sizeof(struct mem_section) * NR_SECTION_ROOTS; > + align = 1 << (INTERNODE_CACHE_SHIFT); > + mem_section = memblock_virt_alloc(size, align); > + } > +#endif > + > for_each_mem_pfn_range(i, nid, _pfn, _pfn, _nid) > memory_present(this_nid, start_pfn, end_pfn); > } > --- a/mm/sparse.c > +++ b/mm/sparse.c > @@ -23,8 +23,7 @@ > * 1) mem_section- memory sections, mem_map's for valid memory > */ > #ifdef CONFIG_SPARSEMEM_EXTREME > -struct mem_section *mem_section[NR_SECTION_ROOTS] > - cacheline_internodealigned_in_smp; > +struct mem_section **mem_section; > #else > struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT] > cacheline_internodealigned_in_smp; > @@ -101,7 +100,7 @@ static inline int sparse_index_init(unsi > int __section_nr(struct mem_section* ms) > { > unsigned long root_nr; > - struct mem_section* root; > + struct mem_section *root = NULL; > > for (root_nr = 0; root_nr < NR_SECTION_ROOTS; root_nr++) { > root = __nr_to_section(root_nr * SECTIONS_PER_ROOT); > @@ -112,7 +111,7 @@ int __section_nr(struct mem_section* ms) >break; > } > > - VM_BUG_ON(root_nr == NR_SECTION_ROOTS); > + VM_BUG_ON(!root); > > return (root_nr * SECTIONS_PER_ROOT) + (ms - root); > } > @@ -330,11 +329,17 @@ again: > static void __init check_usemap_section_nr(int nid, unsigned long *usemap) > { > unsigned long usemap_snr, pgdat_snr; > - static unsigned long old_usemap_snr = NR_MEM_SECTIONS; > - static unsigned long old_pgdat_snr = NR_MEM_SECTIONS; > + static unsigned long old_usemap_snr; > + static unsigned long old_pgdat_snr; > struct pglist_data *pgdat = NODE_DATA(nid); > int usemap_nid; > > + /* First call */ > + if (!old_usemap_snr) { > + old_usemap_snr = NR_MEM_SECTIONS; > +
Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
On Fri, Dec 22, 2017 at 09:45:08AM +0100, Greg Kroah-Hartman wrote: > 4.14-stable review patch. If anyone has any objections, please let me know. > > -- > > From: Kirill A. Shutemov > > commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 upstream. > > Size of the mem_section[] array depends on the size of the physical address > space. > > In preparation for boot-time switching between paging modes on x86-64 > we need to make the allocation of mem_section[] dynamic, because otherwise > we waste a lot of RAM: with CONFIG_NODE_SHIFT=10, mem_section[] size is 32kB > for 4-level paging and 2MB for 5-level paging mode. > > The patch allocates the array on the first call to > sparse_memory_present_with_active_regions(). > > Signed-off-by: Kirill A. Shutemov > Cc: Andrew Morton > Cc: Andy Lutomirski > Cc: Borislav Petkov > Cc: Cyrill Gorcunov > Cc: Linus Torvalds > Cc: Peter Zijlstra > Cc: Thomas Gleixner > Cc: linux...@kvack.org > Link: > http://lkml.kernel.org/r/20170929140821.37654-2-kirill.shute...@linux.intel.com > Signed-off-by: Ingo Molnar > Signed-off-by: Greg Kroah-Hartman This patch causes a boot failure on arm64. Please drop this patch, or pick up the fix in: commit 629a359bdb0e0652a8227b4ff3125431995fec6e Author: Kirill A. Shutemov Date: Tue Nov 7 11:33:37 2017 +0300 mm/sparsemem: Fix ARM64 boot crash when CONFIG_SPARSEMEM_EXTREME=y See https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1527427.html > > --- > include/linux/mmzone.h |6 +- > mm/page_alloc.c| 10 ++ > mm/sparse.c| 17 +++-- > 3 files changed, 26 insertions(+), 7 deletions(-) > > --- a/include/linux/mmzone.h > +++ b/include/linux/mmzone.h > @@ -1152,13 +1152,17 @@ struct mem_section { > #define SECTION_ROOT_MASK(SECTIONS_PER_ROOT - 1) > > #ifdef CONFIG_SPARSEMEM_EXTREME > -extern struct mem_section *mem_section[NR_SECTION_ROOTS]; > +extern struct mem_section **mem_section; > #else > extern struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT]; > #endif > > static inline struct mem_section *__nr_to_section(unsigned long nr) > { > +#ifdef CONFIG_SPARSEMEM_EXTREME > + if (!mem_section) > + return NULL; > +#endif > if (!mem_section[SECTION_NR_TO_ROOT(nr)]) > return NULL; > return _section[SECTION_NR_TO_ROOT(nr)][nr & SECTION_ROOT_MASK]; > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -5651,6 +5651,16 @@ void __init sparse_memory_present_with_a > unsigned long start_pfn, end_pfn; > int i, this_nid; > > +#ifdef CONFIG_SPARSEMEM_EXTREME > + if (!mem_section) { > + unsigned long size, align; > + > + size = sizeof(struct mem_section) * NR_SECTION_ROOTS; > + align = 1 << (INTERNODE_CACHE_SHIFT); > + mem_section = memblock_virt_alloc(size, align); > + } > +#endif > + > for_each_mem_pfn_range(i, nid, _pfn, _pfn, _nid) > memory_present(this_nid, start_pfn, end_pfn); > } > --- a/mm/sparse.c > +++ b/mm/sparse.c > @@ -23,8 +23,7 @@ > * 1) mem_section- memory sections, mem_map's for valid memory > */ > #ifdef CONFIG_SPARSEMEM_EXTREME > -struct mem_section *mem_section[NR_SECTION_ROOTS] > - cacheline_internodealigned_in_smp; > +struct mem_section **mem_section; > #else > struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT] > cacheline_internodealigned_in_smp; > @@ -101,7 +100,7 @@ static inline int sparse_index_init(unsi > int __section_nr(struct mem_section* ms) > { > unsigned long root_nr; > - struct mem_section* root; > + struct mem_section *root = NULL; > > for (root_nr = 0; root_nr < NR_SECTION_ROOTS; root_nr++) { > root = __nr_to_section(root_nr * SECTIONS_PER_ROOT); > @@ -112,7 +111,7 @@ int __section_nr(struct mem_section* ms) >break; > } > > - VM_BUG_ON(root_nr == NR_SECTION_ROOTS); > + VM_BUG_ON(!root); > > return (root_nr * SECTIONS_PER_ROOT) + (ms - root); > } > @@ -330,11 +329,17 @@ again: > static void __init check_usemap_section_nr(int nid, unsigned long *usemap) > { > unsigned long usemap_snr, pgdat_snr; > - static unsigned long old_usemap_snr = NR_MEM_SECTIONS; > - static unsigned long old_pgdat_snr = NR_MEM_SECTIONS; > + static unsigned long old_usemap_snr; > + static unsigned long old_pgdat_snr; > struct pglist_data *pgdat = NODE_DATA(nid); > int usemap_nid; > > + /* First call */ > + if (!old_usemap_snr) { > + old_usemap_snr = NR_MEM_SECTIONS; > + old_pgdat_snr = NR_MEM_SECTIONS; > + } > + > usemap_snr = pfn_to_section_nr(__pa(usemap) >> PAGE_SHIFT); > pgdat_snr = pfn_to_section_nr(__pa(pgdat) >> PAGE_SHIFT); > if (usemap_snr == pgdat_snr) > >
[PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
4.14-stable review patch. If anyone has any objections, please let me know. -- From: Kirill A. Shutemovcommit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 upstream. Size of the mem_section[] array depends on the size of the physical address space. In preparation for boot-time switching between paging modes on x86-64 we need to make the allocation of mem_section[] dynamic, because otherwise we waste a lot of RAM: with CONFIG_NODE_SHIFT=10, mem_section[] size is 32kB for 4-level paging and 2MB for 5-level paging mode. The patch allocates the array on the first call to sparse_memory_present_with_active_regions(). Signed-off-by: Kirill A. Shutemov Cc: Andrew Morton Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Cyrill Gorcunov Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux...@kvack.org Link: http://lkml.kernel.org/r/20170929140821.37654-2-kirill.shute...@linux.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman --- include/linux/mmzone.h |6 +- mm/page_alloc.c| 10 ++ mm/sparse.c| 17 +++-- 3 files changed, 26 insertions(+), 7 deletions(-) --- a/include/linux/mmzone.h +++ b/include/linux/mmzone.h @@ -1152,13 +1152,17 @@ struct mem_section { #define SECTION_ROOT_MASK (SECTIONS_PER_ROOT - 1) #ifdef CONFIG_SPARSEMEM_EXTREME -extern struct mem_section *mem_section[NR_SECTION_ROOTS]; +extern struct mem_section **mem_section; #else extern struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT]; #endif static inline struct mem_section *__nr_to_section(unsigned long nr) { +#ifdef CONFIG_SPARSEMEM_EXTREME + if (!mem_section) + return NULL; +#endif if (!mem_section[SECTION_NR_TO_ROOT(nr)]) return NULL; return _section[SECTION_NR_TO_ROOT(nr)][nr & SECTION_ROOT_MASK]; --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -5651,6 +5651,16 @@ void __init sparse_memory_present_with_a unsigned long start_pfn, end_pfn; int i, this_nid; +#ifdef CONFIG_SPARSEMEM_EXTREME + if (!mem_section) { + unsigned long size, align; + + size = sizeof(struct mem_section) * NR_SECTION_ROOTS; + align = 1 << (INTERNODE_CACHE_SHIFT); + mem_section = memblock_virt_alloc(size, align); + } +#endif + for_each_mem_pfn_range(i, nid, _pfn, _pfn, _nid) memory_present(this_nid, start_pfn, end_pfn); } --- a/mm/sparse.c +++ b/mm/sparse.c @@ -23,8 +23,7 @@ * 1) mem_section - memory sections, mem_map's for valid memory */ #ifdef CONFIG_SPARSEMEM_EXTREME -struct mem_section *mem_section[NR_SECTION_ROOTS] - cacheline_internodealigned_in_smp; +struct mem_section **mem_section; #else struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT] cacheline_internodealigned_in_smp; @@ -101,7 +100,7 @@ static inline int sparse_index_init(unsi int __section_nr(struct mem_section* ms) { unsigned long root_nr; - struct mem_section* root; + struct mem_section *root = NULL; for (root_nr = 0; root_nr < NR_SECTION_ROOTS; root_nr++) { root = __nr_to_section(root_nr * SECTIONS_PER_ROOT); @@ -112,7 +111,7 @@ int __section_nr(struct mem_section* ms) break; } - VM_BUG_ON(root_nr == NR_SECTION_ROOTS); + VM_BUG_ON(!root); return (root_nr * SECTIONS_PER_ROOT) + (ms - root); } @@ -330,11 +329,17 @@ again: static void __init check_usemap_section_nr(int nid, unsigned long *usemap) { unsigned long usemap_snr, pgdat_snr; - static unsigned long old_usemap_snr = NR_MEM_SECTIONS; - static unsigned long old_pgdat_snr = NR_MEM_SECTIONS; + static unsigned long old_usemap_snr; + static unsigned long old_pgdat_snr; struct pglist_data *pgdat = NODE_DATA(nid); int usemap_nid; + /* First call */ + if (!old_usemap_snr) { + old_usemap_snr = NR_MEM_SECTIONS; + old_pgdat_snr = NR_MEM_SECTIONS; + } + usemap_snr = pfn_to_section_nr(__pa(usemap) >> PAGE_SHIFT); pgdat_snr = pfn_to_section_nr(__pa(pgdat) >> PAGE_SHIFT); if (usemap_snr == pgdat_snr)
[PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y
4.14-stable review patch. If anyone has any objections, please let me know. -- From: Kirill A. Shutemov commit 83e3c48729d9ebb7af5a31a504f3fd6aff0348c4 upstream. Size of the mem_section[] array depends on the size of the physical address space. In preparation for boot-time switching between paging modes on x86-64 we need to make the allocation of mem_section[] dynamic, because otherwise we waste a lot of RAM: with CONFIG_NODE_SHIFT=10, mem_section[] size is 32kB for 4-level paging and 2MB for 5-level paging mode. The patch allocates the array on the first call to sparse_memory_present_with_active_regions(). Signed-off-by: Kirill A. Shutemov Cc: Andrew Morton Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Cyrill Gorcunov Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux...@kvack.org Link: http://lkml.kernel.org/r/20170929140821.37654-2-kirill.shute...@linux.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman --- include/linux/mmzone.h |6 +- mm/page_alloc.c| 10 ++ mm/sparse.c| 17 +++-- 3 files changed, 26 insertions(+), 7 deletions(-) --- a/include/linux/mmzone.h +++ b/include/linux/mmzone.h @@ -1152,13 +1152,17 @@ struct mem_section { #define SECTION_ROOT_MASK (SECTIONS_PER_ROOT - 1) #ifdef CONFIG_SPARSEMEM_EXTREME -extern struct mem_section *mem_section[NR_SECTION_ROOTS]; +extern struct mem_section **mem_section; #else extern struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT]; #endif static inline struct mem_section *__nr_to_section(unsigned long nr) { +#ifdef CONFIG_SPARSEMEM_EXTREME + if (!mem_section) + return NULL; +#endif if (!mem_section[SECTION_NR_TO_ROOT(nr)]) return NULL; return _section[SECTION_NR_TO_ROOT(nr)][nr & SECTION_ROOT_MASK]; --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -5651,6 +5651,16 @@ void __init sparse_memory_present_with_a unsigned long start_pfn, end_pfn; int i, this_nid; +#ifdef CONFIG_SPARSEMEM_EXTREME + if (!mem_section) { + unsigned long size, align; + + size = sizeof(struct mem_section) * NR_SECTION_ROOTS; + align = 1 << (INTERNODE_CACHE_SHIFT); + mem_section = memblock_virt_alloc(size, align); + } +#endif + for_each_mem_pfn_range(i, nid, _pfn, _pfn, _nid) memory_present(this_nid, start_pfn, end_pfn); } --- a/mm/sparse.c +++ b/mm/sparse.c @@ -23,8 +23,7 @@ * 1) mem_section - memory sections, mem_map's for valid memory */ #ifdef CONFIG_SPARSEMEM_EXTREME -struct mem_section *mem_section[NR_SECTION_ROOTS] - cacheline_internodealigned_in_smp; +struct mem_section **mem_section; #else struct mem_section mem_section[NR_SECTION_ROOTS][SECTIONS_PER_ROOT] cacheline_internodealigned_in_smp; @@ -101,7 +100,7 @@ static inline int sparse_index_init(unsi int __section_nr(struct mem_section* ms) { unsigned long root_nr; - struct mem_section* root; + struct mem_section *root = NULL; for (root_nr = 0; root_nr < NR_SECTION_ROOTS; root_nr++) { root = __nr_to_section(root_nr * SECTIONS_PER_ROOT); @@ -112,7 +111,7 @@ int __section_nr(struct mem_section* ms) break; } - VM_BUG_ON(root_nr == NR_SECTION_ROOTS); + VM_BUG_ON(!root); return (root_nr * SECTIONS_PER_ROOT) + (ms - root); } @@ -330,11 +329,17 @@ again: static void __init check_usemap_section_nr(int nid, unsigned long *usemap) { unsigned long usemap_snr, pgdat_snr; - static unsigned long old_usemap_snr = NR_MEM_SECTIONS; - static unsigned long old_pgdat_snr = NR_MEM_SECTIONS; + static unsigned long old_usemap_snr; + static unsigned long old_pgdat_snr; struct pglist_data *pgdat = NODE_DATA(nid); int usemap_nid; + /* First call */ + if (!old_usemap_snr) { + old_usemap_snr = NR_MEM_SECTIONS; + old_pgdat_snr = NR_MEM_SECTIONS; + } + usemap_snr = pfn_to_section_nr(__pa(usemap) >> PAGE_SHIFT); pgdat_snr = pfn_to_section_nr(__pa(pgdat) >> PAGE_SHIFT); if (usemap_snr == pgdat_snr)