From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 21E0A32E6BC for ; Fri, 31 Jul 2026 07:07:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785481673; cv=none; b=ZcOX3QHUoN91Hs/vDfwZgVfxAyIPUpWX0ec5ZSJWz9mjJ5+bdMd+Qj4rEifKZKihRQ/zt1ZCNaYNmrSb3H/2bKFeZidF0YA4soLo2DCbZEhQ5gKFxkD9/JLt0UQ/FhO5TgR//GNxMK8//Y5ll7PDuCuymb7Sa0T+nNLP64GOU5A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785481673; c=relaxed/simple; bh=yL9bfksKQx/s120B87vbfxDuRemdRBE71V0OGTf2PVk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=GqK+D3xSN6d6FYFkXBYjeYOWuVuk9ZOKrb/UhjHPH1bp9q1POFGeqpCeklPvfrs/EDfGmLYICpQnsVqqlqDGXreDqHUq5JQe4+tIV7kAZV7RlXqjbkGQ4jooTDRCYmc6IADUt2xhjbpLCqIsvMw0Z6UFg+9XimmXF43kxOfui+s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jqiUjDOb; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jqiUjDOb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5A32A1F000E9; Fri, 31 Jul 2026 07:07:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785481671; bh=jE/jZJ2b8amnc5cylmq6frdPeNVYOhh2qPsnqDWlWqQ=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=jqiUjDOb2GJbulM4kICNrGg1xmIlnoH6ZRX79EiQGqet9qGL98E+aEhpIbVkBnB2e WUOJGbhkg0h+7n6unKewSeGaVMh7IzDpw7y72yVBa1KgeVciiFwPDQUfcsyqYTNDT1 Ddr/Ord0SETBjpneA9FKV76KIVZi9PiYdeCvK3kltHcWowWuuVmk4y+SUFQiWl2KSb Cmmrh8SJB6pXafK2Gd5vdOpNzrQmwnPRCkWgRsiM+mkNCoJmarcmrszChX2ukM+9Hk vOlPDaLXACxxgR3Tb9Tv/s3fx2P3fbLRuU15kQDweGxPmdEAq5KBzsgnrgbz5bzo8u gRRJUJg1StqSg== Message-ID: <544be782-944e-4568-a2ac-4861680829a8@kernel.org> Date: Fri, 31 Jul 2026 09:07:47 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] powerpc/kexec: Simplify kdump_extra_elfcorehdr_size() To: Thorsten Blum Cc: Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , Sourabh Jain , Aditya Gupta , Hari Bathini , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org References: <20260730131940.597739-2-thorsten.blum@linux.dev> <42ab7c21-25cd-4ed1-b43f-b155e82db1a0@kernel.org> Content-Language: fr-FR From: "Christophe Leroy (CS GROUP)" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Le 30/07/2026 à 16:45, Thorsten Blum a écrit : > On Thu, Jul 30, 2026 at 04:33:18PM +0200, Christophe Leroy (CS GROUP) wrote: >> Le 30/07/2026 à 15:19, Thorsten Blum a écrit : >>> Return the size directly and drop the extra_sz variable to simplify >>> kdump_extra_elfcorehdr_size(). The two warning paths now fall through >>> to the existing return 0 at the end of the function. >>> >>> Signed-off-by: Thorsten Blum >>> --- >>> arch/powerpc/kexec/file_load_64.c | 6 +----- >>> 1 file changed, 1 insertion(+), 5 deletions(-) >>> >>> diff --git a/arch/powerpc/kexec/file_load_64.c b/arch/powerpc/kexec/file_load_64.c >>> index c3503d698428..d0c544079e03 100644 >>> --- a/arch/powerpc/kexec/file_load_64.c >>> +++ b/arch/powerpc/kexec/file_load_64.c >>> @@ -377,16 +377,12 @@ static int load_backup_segment(struct kimage *image, struct kexec_buf *kbuf) >>> static unsigned int kdump_extra_elfcorehdr_size(struct crash_mem *cmem) >>> { >>> #if defined(CONFIG_CRASH_HOTPLUG) && defined(CONFIG_MEMORY_HOTPLUG) >>> - unsigned int extra_sz = 0; >>> - >>> if (CONFIG_CRASH_MAX_MEMORY_RANGES > (unsigned int)PN_XNUM) >>> pr_warn("Number of Phdrs %u exceeds max\n", CONFIG_CRASH_MAX_MEMORY_RANGES); >>> else if (cmem->nr_ranges >= CONFIG_CRASH_MAX_MEMORY_RANGES) >>> pr_warn("Configured crash mem ranges may not be enough\n"); >>> else >>> - extra_sz = (CONFIG_CRASH_MAX_MEMORY_RANGES - cmem->nr_ranges) * sizeof(Elf64_Phdr); >>> - >>> - return extra_sz; >>> + return (CONFIG_CRASH_MAX_MEMORY_RANGES - cmem->nr_ranges) * sizeof(Elf64_Phdr); >> >> I don't understand. >> >> Previously, when cmem->nr_ranges >= CONFIG_CRASH_MAX_MEMORY_RANGES you would >> return 0. Now you will return something different. For instance if >> cmem->nr_ranges is (CONFIG_CRASH_MAX_MEMORY_RANGES + 1) you will return >> (unsigned int)(-1 * sizeof(Elf64_Phdr)) > > It still returns 0. > > When cmem->nr_ranges >= CONFIG_CRASH_MAX_MEMORY_RANGES, the else if > branch prints the warning and then falls through to the return 0 at the > end of the function. The final else branch is not entered in that case. Hum ... Yes sorry I missed that. Reviewed-by: Christophe Leroy (CS GROUP) > > No functional changes are intended. > >>> #endif >>> return 0; >>> } >>