On Tue, Dec 23 2025, Pasha Tatashin wrote: > On Tue, Dec 23, 2025 at 5:45 AM Pratyush Yadav <[email protected]> wrote: >> >> When restoring a page (from kho_restore_pages()) or folio (from >> kho_restore_folio()), KHO must initialize the struct page. The >> initialization differs slightly depending on if a folio is requested or >> a set of 0-order pages is requested. >> >> Conceptually, it is quite simple to understand. When restoring 0-order >> pages, each page gets a refcount of 1 and that's it. When restoring a >> folio, head page gets a refcount of 1 and tail pages get 0. >> >> kho_restore_page() tries to combine the two separate initialization flow >> into one piece of code. While it works fine, it is more complicated to >> read than it needs to be. Make the code simpler by splitting the two >> initalization paths into two separate functions. This improves >> readability by clearly showing how each type must be initialized. >> >> Signed-off-by: Pratyush Yadav <[email protected]> >> --- >> >> Notes: >> This patch is a follow up from >> https://lore.kernel.org/linux-mm/[email protected]/ >> >> kernel/liveupdate/kexec_handover.c | 41 ++++++++++++++++++++---------- >> 1 file changed, 27 insertions(+), 14 deletions(-) >> >> diff --git a/kernel/liveupdate/kexec_handover.c >> b/kernel/liveupdate/kexec_handover.c >> index 2d9ce33c63dc..304c26fd5ee6 100644 >> --- a/kernel/liveupdate/kexec_handover.c >> +++ b/kernel/liveupdate/kexec_handover.c >> @@ -219,11 +219,33 @@ static int __kho_preserve_order(struct kho_mem_track >> *track, unsigned long pfn, >> return 0; >> } >> >> +/* For physically contiguous 0-order pages. */ >> +static void kho_init_pages(struct page *page, unsigned int nr_pages) > > Here and in other places below, it is better for nr_pages to be > unsigned long. This is consistent with other places in mm, where we > have gradually moved on from int/unsigned int to unsigned long for > npages (see gup.c for example). Otherwise, LGTM.
Thanks. Will do. [...] -- Regards, Pratyush Yadav
