All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: Usama Arif <usamaarif642@gmail.com>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	kas@kernel.org, changyuanl@google.com, graf@amazon.com,
	leitao@debian.org, thevlad@meta.com, pratyush@kernel.org,
	dave.hansen@linux.intel.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, kernel-team@meta.com
Subject: Re: [PATCH v3 2/2] mm/memblock: only mark/clear KHO scratch memory when needed
Date: Sun, 7 Dec 2025 16:57:38 +0200	[thread overview]
Message-ID: <aTWV4vnTAYwoH1ZE@kernel.org> (raw)
In-Reply-To: <657d2356-126d-452b-ba7f-5c0761f4f832@gmail.com>

On Thu, Dec 04, 2025 at 07:27:29PM +0000, Usama Arif wrote:
> On 04/12/2025 17:52, Mike Rapoport wrote:
> >>
> >> So the patch was designed to remove the memblock_mark_kho_scratch in e820__memblock_setup if not
> >> in KHO boot. But it broke memblock_mark_kho_scratch in kho_populate.
> >> Moving kho_in.fdt_phys = fdt_phys to before the memblock_mark_scratch
> >> should fix it. I dont have a setup where I can easily test KHO, but I think below
> >> should fix it?

There's a simple KHO sefltest in tools/testing/selftest/kho

> > This might, but this is too late for v6.19-rc1.
> > For now I'm dropping this series from memblock/for-next.
> > We can resume working on this after merge window closes.
> >  
> 
> Yes makes sense.
> 
> How would you like me to proceed with the fix? Should I send just the fix now,
> or these 2 patches plus the fix after the merge window closes?

The fix should come before the changes in memblock_mark_kho_scratch(), so
please resend the whole series.
 
> >> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
> >> index 9dc51fab604f1..c331749e6452e 100644
> >> --- a/kernel/liveupdate/kexec_handover.c
> >> +++ b/kernel/liveupdate/kexec_handover.c
> >> @@ -1483,6 +1483,7 @@ void __init kho_populate(phys_addr_t fdt_phys, u64 fdt_len,
> >>                 goto out;
> >>         }
> >>  
> >> +       kho_in.fdt_phys = fdt_phys;

This should happen before the calls to memblock_mark_kho_scratch().

> >>         /*
> >>          * We pass a safe contiguous blocks of memory to use for early boot
> >>          * purporses from the previous kernel so that we can resize the
> >> @@ -1513,7 +1514,6 @@ void __init kho_populate(phys_addr_t fdt_phys, u64 fdt_len,
> >>          */
> >>         memblock_set_kho_scratch_only();
> >>  
> >> -       kho_in.fdt_phys = fdt_phys;
> >>         kho_in.scratch_phys = scratch_phys;
> >>         kho_scratch_cnt = scratch_cnt;
> >>         pr_info("found kexec handover data.\n");
> >> @@ -1524,7 +1524,10 @@ void __init kho_populate(phys_addr_t fdt_phys, u64 fdt_len,
> >>         if (scratch)
> >>                 early_memunmap(scratch, scratch_len);
> >>         if (err)
> >> +       {
> >> +               kho_in.fdt_phys = 0;
> >>                 pr_warn("disabling KHO revival: %d\n", err);
> >> +       }
> >>  }
> > 
> 

-- 
Sincerely yours,
Mike.


      reply	other threads:[~2025-12-07 14:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-28 17:29 [PATCH v3 0/2] mm: only mark/clear KHO scratch memory when needed Usama Arif
2025-11-28 17:29 ` [PATCH v3 1/2] mm/memblock: remove CONFIG_MEMBLOCK_KHO_SCRATCH option Usama Arif
2025-11-28 17:29 ` [PATCH v3 2/2] mm/memblock: only mark/clear KHO scratch memory when needed Usama Arif
2025-11-30  8:52   ` Mike Rapoport
2025-12-04 14:04     ` Pasha Tatashin
2025-12-04 14:51       ` Usama Arif
2025-12-04 17:52         ` Mike Rapoport
2025-12-04 19:27           ` Usama Arif
2025-12-07 14:57             ` Mike Rapoport [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=aTWV4vnTAYwoH1ZE@kernel.org \
    --to=rppt@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=changyuanl@google.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=graf@amazon.com \
    --cc=kas@kernel.org \
    --cc=kernel-team@meta.com \
    --cc=leitao@debian.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=pasha.tatashin@soleen.com \
    --cc=pratyush@kernel.org \
    --cc=thevlad@meta.com \
    --cc=usamaarif642@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.