LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Sourabh Jain <sourabhjain@linux.ibm.com>
To: Thorsten Blum <thorsten.blum@linux.dev>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Nicholas Piggin <npiggin@gmail.com>,
	"Christophe Leroy (CS GROUP)" <chleroy@kernel.org>,
	Hari Bathini <hbathini@linux.ibm.com>,
	Aditya Gupta <adityag@linux.ibm.com>,
	Jinjie Ruan <ruanjinjie@huawei.com>,
	Thiago Jung Bauermann <bauerman@linux.ibm.com>,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] powerpc/kexec_file: Use inclusive range checks in add_usable_mem()
Date: Wed, 12 Aug 2026 08:41:59 +0530	[thread overview]
Message-ID: <b650f898-f0f3-4223-a507-3d833ab5c725@linux.ibm.com> (raw)
In-Reply-To: <anr_k9jzc2QYjsJz@linux.dev>



On 11/08/26 16:25, Thorsten Blum wrote:
> On Tue, Aug 11, 2026 at 11:51:46AM +0530, Sourabh Jain wrote:
>> On 09/08/26 21:54, Thorsten Blum wrote:
>>> add_usable_mem() adds usable memory ranges for the kdump kernel.
>>>
>>> The ranges are inclusive, but the partial overlap check uses exclusive
>>> comparisons. This skips ranges with base == loc_end or end == loc_base.
>>> Use inclusive comparisons instead.
>>>
>>> Fixes: 7c64e21a1c5a ("powerpc/kexec_file: Restrict memory usage of kdump kernel")
>>> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
>>> ---
>>>    arch/powerpc/kexec/file_load_64.c | 2 +-
>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/powerpc/kexec/file_load_64.c b/arch/powerpc/kexec/file_load_64.c
>>> index 8c72e12ea44e..f9e872693ca7 100644
>>> --- a/arch/powerpc/kexec/file_load_64.c
>>> +++ b/arch/powerpc/kexec/file_load_64.c
>>> @@ -113,7 +113,7 @@ static int add_usable_mem(struct umem_info *um_info, u64 base, u64 end)
>>>    		loc_end = um_info->ranges[i].end;
>>>    		if (loc_base >= base && loc_end <= end)
>>>    			add = true;
>>> -		else if (base < loc_end && end > loc_base) {
>>> +		else if (base <= loc_end && end >= loc_base) {
>> This is interesting. The updated condition basically handles exactly a
>> one-byte overlap on either side of the usable memory ranges. In practice,
>> it is very unlikely that we would have such usable memory and LMB ranges.
>>
>> Thorsten, have you encountered any problem that led you to propose this fix?
> Found by inspection only and I agree that this is unlikely in practice,
> which is why I didn't cc stable. Same for the other patch [1].
>
> Thanks for the review.
>
> [1] https://lore.kernel.org/r/20260810145827.157972-3-thorsten.blum@linux.dev/

The changes look good to me. Feel free to add:

Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>


      reply	other threads:[~2026-08-12  3:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-09 16:24 [PATCH] powerpc/kexec_file: Use inclusive range checks in add_usable_mem() Thorsten Blum
2026-08-11  6:21 ` Sourabh Jain
2026-08-11 10:55   ` Thorsten Blum
2026-08-12  3:11     ` Sourabh Jain [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b650f898-f0f3-4223-a507-3d833ab5c725@linux.ibm.com \
    --to=sourabhjain@linux.ibm.com \
    --cc=adityag@linux.ibm.com \
    --cc=bauerman@linux.ibm.com \
    --cc=chleroy@kernel.org \
    --cc=hbathini@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=ruanjinjie@huawei.com \
    --cc=thorsten.blum@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox