Received: by 10.223.176.5 with SMTP id f5csp1340268wra; Wed, 7 Feb 2018 17:45:36 -0800 (PST) X-Google-Smtp-Source: AH8x226FI7ZAoZX0l8CtEFNeJCoFCg4ruvIOLIrdfIpFn0REKG+JvlZP+8TRBKhhB7UyCkGIzJ/d X-Received: by 2002:a17:902:274a:: with SMTP id j10-v6mr7836761plg.107.1518054336248; Wed, 07 Feb 2018 17:45:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518054336; cv=none; d=google.com; s=arc-20160816; b=sShaHMWt8Ycz4pNswaFXpJ1In2+JwBSxV6gfZehU+0TJTNLii9eMWOHtRoxORmYk/A +AG4WHGHUY5MxWnM9J6/AAu7+BPOm8c1x2xkHscQ/np9OhKQmtjLRquggb2sWTXMITR7 BVdWiVTmSEPouVsGUE2tWPGbGGQHGgxBOd1ym0vA3fiO5fadgduHf2zVchowqAHUMjaK rqTSWGa2KZM6p5VZ90tq7Y8oYIsZlwQNPu/6AGVKmo3UAlbZrKEA5bezeMRbXrT7LfrF st8n/fgbrIQDRbvM7IkSI8IcIBrU7mWqjajM/mdiiOcCStNzfwI1gr8UBbE/jghqJpJA 2Wcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=Pt73Y/hBSGIT2hL7VxDLJs99nz3uI/uOWQDKl3/9Udw=; b=n+J3ZmbXFRxfdId3bsDwKppiTNGWrbndPEjm9Lla96GbbROh0qF9FhnvTkMAjlxmyG bjTSS33UB/8plwRfJ/rXNyqpJXmiPGAV8f1abiC1gWQ2kLRD6nm6G+mdag/rAQ/cmXDd s+Sra+KSSG7RFRXQ4hf449Bw/oV7npLCO0o1B3XfWnHjnLorHQiWEJCqYN+/xA1gM6LA mWxZXz8k39H3q6U9+WgYOO7AsuPsptsFhtaLmH3oX6U2fCiw5NYV81pH7IvAamCKCNFS edAWGDqcQh6LPw9Th2wL3/naOVkXtqMndVVYV//cg4Yz2E2Su+cANPgjMitr/MEtqg/z ngsw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 15si1980328pfq.361.2018.02.07.17.45.22; Wed, 07 Feb 2018 17:45:36 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751738AbeBHBog (ORCPT + 99 others); Wed, 7 Feb 2018 20:44:36 -0500 Received: from mail.cn.fujitsu.com ([183.91.158.132]:6781 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750987AbeBHBoe (ORCPT ); Wed, 7 Feb 2018 20:44:34 -0500 X-IronPort-AV: E=Sophos;i="5.43,368,1503331200"; d="scan'208";a="36910644" Received: from bogon (HELO cn.fujitsu.com) ([10.167.33.5]) by heian.cn.fujitsu.com with ESMTP; 08 Feb 2018 09:44:32 +0800 Received: from G08CNEXCHPEKD02.g08.fujitsu.local (unknown [10.167.33.83]) by cn.fujitsu.com (Postfix) with ESMTP id 37B0F48AE763; Thu, 8 Feb 2018 09:44:31 +0800 (CST) Received: from localhost.localdomain (10.167.226.106) by G08CNEXCHPEKD02.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 8 Feb 2018 09:44:30 +0800 Subject: Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y To: Baoquan He CC: Takao Indoh , Peter Zijlstra , Greg Kroah-Hartman , Mike Galbraith , , , , Andy Lutomirski , , Thomas Gleixner , "Kirill A. Shutemov" , Linus Torvalds , Cyrill Gorcunov , "Kirill A. Shutemov" , Andrew Morton , Borislav Petkov , Dave Young , Ingo Molnar , Vivek Goyal 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 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 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 X-Originating-IP: [10.167.226.106] X-yoursite-MailScanner-ID: 37B0F48AE763.AE0AA X-yoursite-MailScanner: Found to be clean X-yoursite-MailScanner-From: douly.fnst@cn.fujitsu.com X-Spam-Status: No Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > > >