From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5] helo=mx0a-001b2d01.pphosted.com) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jz88I-0002os-3v for kexec@lists.infradead.org; Sat, 25 Jul 2020 00:33:47 +0000 References: <159524918900.20855.17709718993097359220.stgit@hbathini.in.ibm.com> <159524954805.20855.1164928096364700614.stgit@hbathini.in.ibm.com> <875zad6ajx.fsf@morokweng.localdomain> <77c606da-8eb2-d831-147b-a204b498c7d7@linux.ibm.com> From: Thiago Jung Bauermann Subject: Re: [PATCH v4 06/12] ppc64/kexec_file: restrict memory usage of kdump kernel In-reply-to: <77c606da-8eb2-d831-147b-a204b498c7d7@linux.ibm.com> Date: Fri, 24 Jul 2020 21:32:59 -0300 Message-ID: <874kpwsabo.fsf@morokweng.localdomain> MIME-Version: 1.0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Hari Bathini Cc: Pingfan Liu , Petr Tesarik , Nayna Jain , Kexec-ml , Mahesh J Salgaonkar , Mimi Zohar , lkml , linuxppc-dev , Sourabh Jain , Andrew Morton , Dave Young , Vivek Goyal , Eric Biederman Hari Bathini writes: > On 24/07/20 5:36 am, Thiago Jung Bauermann wrote: >> >> Hari Bathini writes: >> >>> Kdump kernel, used for capturing the kernel core image, is supposed >>> to use only specific memory regions to avoid corrupting the image to >>> be captured. The regions are crashkernel range - the memory reserved >>> explicitly for kdump kernel, memory used for the tce-table, the OPAL >>> region and RTAS region as applicable. Restrict kdump kernel memory >>> to use only these regions by setting up usable-memory DT property. >>> Also, tell the kdump kernel to run at the loaded address by setting >>> the magic word at 0x5c. >>> >>> Signed-off-by: Hari Bathini >>> Tested-by: Pingfan Liu >>> --- >>> >>> v3 -> v4: >>> * Updated get_node_path() to be an iterative function instead of a >>> recursive one. >>> * Added comment explaining why low memory is added to kdump kernel's >>> usable memory ranges though it doesn't fall in crashkernel region. >>> * For correctness, added fdt_add_mem_rsv() for the low memory being >>> added to kdump kernel's usable memory ranges. >> >> Good idea. >> >>> * Fixed prop pointer update in add_usable_mem_property() and changed >>> duple to tuple as suggested by Thiago. >> >> >> >>> +/** >>> + * get_node_pathlen - Get the full path length of the given node. >>> + * @dn: Node. >>> + * >>> + * Also, counts '/' at the end of the path. >>> + * For example, /memory@0 will be "/memory@0/\0" => 11 bytes. >> >> Wouldn't this function return 10 in the case of /memory@0? > > Actually, it does return 11. +1 while returning is for counting %NUL. > On top of that we count an extra '/' for root node.. so, it ends up as 11. > ('/'memory@0'/''\0'). Note the extra '/' before '\0'. Let me handle root node > separately. That should avoid the confusion. Ah, that is true. I forgot to count the iteration for the root node. Sorry about that. -- Thiago Jung Bauermann IBM Linux Technology Center _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec