From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl0-f72.google.com (mail-pl0-f72.google.com [209.85.160.72]) by kanga.kvack.org (Postfix) with ESMTP id E40936B0003 for ; Wed, 7 Feb 2018 20:44:34 -0500 (EST) Received: by mail-pl0-f72.google.com with SMTP id n11-v6so874553plp.13 for ; Wed, 07 Feb 2018 17:44:34 -0800 (PST) Received: from heian.cn.fujitsu.com (mail.cn.fujitsu.com. [183.91.158.132]) by mx.google.com with ESMTP id t79si661380pfi.184.2018.02.07.17.44.32 for ; Wed, 07 Feb 2018 17:44:33 -0800 (PST) Subject: Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y References: <20180207104111.sljc62bgkggmtio4@node.shutemov.name> <1518000336.29698.1.camel@gmx.de> <20180207120827.GB30270@localhost.localdomain> <2945e12f-caab-b7e7-77e0-bd3971e784be@cn.fujitsu.com> <20180207122724.GC30270@localhost.localdomain> <0a2d5abe-3081-a784-dd85-70d34a0f60cc@cn.fujitsu.com> <20180207124519.GD30270@localhost.localdomain> <0988774f-9de0-b18f-1216-57d802502bb7@cn.fujitsu.com> <20180208012323.GE30270@localhost.localdomain> From: Dou Liyang Message-ID: Date: Thu, 8 Feb 2018 09:44:20 +0800 MIME-Version: 1.0 In-Reply-To: <20180208012323.GE30270@localhost.localdomain> Content-Type: text/plain; charset="gbk"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Baoquan He Cc: Takao Indoh , Peter Zijlstra , Greg Kroah-Hartman , Mike Galbraith , kexec@lists.infradead.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Andy Lutomirski , linux-mm@kvack.org, Thomas Gleixner , "Kirill A. Shutemov" , Linus Torvalds , Cyrill Gorcunov , "Kirill A. Shutemov" , Andrew Morton , Borislav Petkov , Dave Young , Ingo Molnar , Vivek Goyal 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 : 1000000 >>>> phys_end : 2a86000 >>>> virt_start : ffffffff81000000 >>>> virt_end : ffffffff82a86000 >>>> LOAD (1) >>>> phys_start : 1000 >>>> phys_end : 9fc00 >>>> virt_start : ffff880000001000 >>>> virt_end : ffff88000009fc00 >>>> LOAD (2) >>>> phys_start : 100000 >>>> phys_end : 13000000 >>>> virt_start : ffff880000100000 >>>> virt_end : ffff880013000000 >>>> LOAD (3) >>>> phys_start : 33000000 >>>> phys_end : 7ffd7000 >>>> virt_start : ffff880033000000 >>>> virt_end : ffff88007ffd7000 >>>> 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 : ffffea0000000000 >>>> pfn_start : 0 >>>> pfn_end : 8000 >>>> mem_map (1) >>>> mem_map : ffffea0000200000 >>>> pfn_start : 8000 >>>> pfn_end : 10000 >>>> mem_map (2) >>>> mem_map : ffffea0000400000 >>>> pfn_start : 10000 >>>> pfn_end : 18000 >>>> mem_map (3) >>>> mem_map : ffffea0000600000 >>>> pfn_start : 18000 >>>> pfn_end : 20000 >>>> mem_map (4) >>>> mem_map : ffffea0000800000 >>>> pfn_start : 20000 >>>> pfn_end : 28000 >>>> mem_map (5) >>>> mem_map : ffffea0000a00000 >>>> pfn_start : 28000 >>>> pfn_end : 30000 >>>> mem_map (6) >>>> mem_map : ffffea0000c00000 >>>> pfn_start : 30000 >>>> pfn_end : 38000 >>>> mem_map (7) >>>> mem_map : ffffea0000e00000 >>>> pfn_start : 38000 >>>> pfn_end : 40000 >>>> mem_map (8) >>>> mem_map : ffffea0001000000 >>>> pfn_start : 40000 >>>> pfn_end : 48000 >>>> mem_map (9) >>>> mem_map : ffffea0001200000 >>>> pfn_start : 48000 >>>> pfn_end : 50000 >>>> mem_map (10) >>>> mem_map : ffffea0001400000 >>>> pfn_start : 50000 >>>> pfn_end : 58000 >>>> mem_map (11) >>>> mem_map : ffffea0001600000 >>>> pfn_start : 58000 >>>> pfn_end : 60000 >>>> mem_map (12) >>>> mem_map : ffffea0001800000 >>>> pfn_start : 60000 >>>> pfn_end : 68000 >>>> mem_map (13) >>>> mem_map : ffffea0001a00000 >>>> pfn_start : 68000 >>>> pfn_end : 70000 >>>> mem_map (14) >>>> mem_map : ffffea0001c00000 >>>> pfn_start : 70000 >>>> pfn_end : 78000 >>>> mem_map (15) >>>> mem_map : ffffea0001e00000 >>>> 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 : 1000000 >>>>>> phys_end : 2a86000 >>>>>> virt_start : ffffffff81000000 >>>>>> virt_end : ffffffff82a86000 >>>>>> LOAD (1) >>>>>> phys_start : 1000 >>>>>> phys_end : 9fc00 >>>>>> virt_start : ffff880000001000 >>>>>> virt_end : ffff88000009fc00 >>>>>> LOAD (2) >>>>>> phys_start : 100000 >>>>>> phys_end : 13000000 >>>>>> virt_start : ffff880000100000 >>>>>> virt_end : ffff880013000000 >>>>>> LOAD (3) >>>>>> phys_start : 33000000 >>>>>> phys_end : 7ffd7000 >>>>>> virt_start : ffff880033000000 >>>>>> virt_end : ffff88007ffd7000 >>>>>> 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 : ffff88007ff26000 >>>>>> pfn_start : 0 >>>>>> pfn_end : 8000 >>>>>> mem_map (1) >>>>>> mem_map : 0 >>>>>> pfn_start : 8000 >>>>>> pfn_end : 10000 >>>>>> mem_map (2) >>>>>> mem_map : 0 >>>>>> pfn_start : 10000 >>>>>> pfn_end : 18000 >>>>>> mem_map (3) >>>>>> mem_map : 0 >>>>>> pfn_start : 18000 >>>>>> pfn_end : 20000 >>>>>> mem_map (4) >>>>>> mem_map : 0 >>>>>> pfn_start : 20000 >>>>>> pfn_end : 28000 >>>>>> mem_map (5) >>>>>> mem_map : 0 >>>>>> pfn_start : 28000 >>>>>> pfn_end : 30000 >>>>>> mem_map (6) >>>>>> mem_map : 0 >>>>>> pfn_start : 30000 >>>>>> pfn_end : 38000 >>>>>> mem_map (7) >>>>>> mem_map : 0 >>>>>> pfn_start : 38000 >>>>>> pfn_end : 40000 >>>>>> mem_map (8) >>>>>> mem_map : 0 >>>>>> pfn_start : 40000 >>>>>> pfn_end : 48000 >>>>>> mem_map (9) >>>>>> mem_map : 0 >>>>>> pfn_start : 48000 >>>>>> pfn_end : 50000 >>>>>> mem_map (10) >>>>>> mem_map : 0 >>>>>> pfn_start : 50000 >>>>>> pfn_end : 58000 >>>>>> mem_map (11) >>>>>> mem_map : 0 >>>>>> pfn_start : 58000 >>>>>> pfn_end : 60000 >>>>>> mem_map (12) >>>>>> mem_map : 0 >>>>>> pfn_start : 60000 >>>>>> pfn_end : 68000 >>>>>> mem_map (13) >>>>>> mem_map : 0 >>>>>> pfn_start : 68000 >>>>>> pfn_end : 70000 >>>>>> mem_map (14) >>>>>> mem_map : 0 >>>>>> pfn_start : 70000 >>>>>> 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.000014 seconds >>>>>> __vtop4_x86_64: Can't get a valid pte. >>>>>> readmem: Can't convert a virtual address(ffff88007ffd7000) to physical >>>>>> address. >>>>>> readmem: type_addr: 0, addr:ffff88007ffd7000, 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.000006 seconds >>>>>> Checking for memory holes : [100.0 %] - STEP >>>>>> [Checking for memory holes ] : 0.000004 seconds >>>>>> __vtop4_x86_64: Can't get a valid pte. >>>>>> readmem: Can't convert a virtual address(ffff88007ffd7000) to physical >>>>>> address. >>>>>> readmem: type_addr: 0, addr:ffff88007ffd7000, size:32768 >>>>>> __exclude_unnecessary_pages: Can't read the buffer of struct page. >>>>>> create_2nd_bitmap: Can't exclude unnecessary pages. >>>>>> >>>>>> makedumpfile Failed. >>>>>> >>>>>>> >>>>>>>> >>>>>>>> ......It causes makedumpfile failed. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> dou. >>>>>>>> >>>>>>>>> -Mike >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> >> >> _______________________________________________ >> kexec mailing list >> kexec@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/kexec > > > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org