From: Mike Rapoport <rppt@kernel.org>
To: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: akpm@linux-foundation.org, brauner@kernel.org, corbet@lwn.net,
graf@amazon.com, jgg@ziepe.ca, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-mm@kvack.org,
masahiroy@kernel.org, ojeda@kernel.org, pratyush@kernel.org,
rdunlap@infradead.org, tj@kernel.org
Subject: Re: [PATCH v8 8/8] memblock: Unpreserve memory in case of error
Date: Mon, 27 Oct 2025 08:58:08 +0200 [thread overview]
Message-ID: <aP8YADj4ha3trjJn@kernel.org> (raw)
In-Reply-To: <CA+CK2bCUc5Q5PxCy3jGN9CC48Zz_evq51d7Hps7=r9g28z7tig@mail.gmail.com>
On Sun, Oct 26, 2025 at 01:41:30PM -0400, Pasha Tatashin wrote:
> On Sun, Oct 26, 2025 at 12:29 PM Mike Rapoport <rppt@kernel.org> wrote:
> >
> > > @@ -2462,12 +2463,14 @@ static int __init prepare_kho_fdt(void)
> > >
> > > err |= fdt_begin_node(fdt, "");
> > > err |= fdt_property_string(fdt, "compatible", MEMBLOCK_KHO_NODE_COMPATIBLE);
> > > - for (i = 0; i < reserved_mem_count; i++) {
> > > + for (i = 0; !err && i < reserved_mem_count; i++) {
> > > struct reserve_mem_table *map = &reserved_mem_table[i];
> > > struct page *page = phys_to_page(map->start);
> > > unsigned int nr_pages = map->size >> PAGE_SHIFT;
> > >
> > > - err |= kho_preserve_pages(page, nr_pages);
> > > + err = kho_preserve_pages(page, nr_pages);
> > > + if (err)
> > > + break;
> >
> > Please
> >
> > goto err_unpreserve;
>
> While we can do that, we loose some symmetry of not performing
> fdt_end_node() and fdt_finish() if fdt lib ever adds some debugging
> facility to make sure that open nodes/trees are properly clodes, this
> is going to flag that. I prefer my current implementation.
Why do we care about fdt that we are never going to use and that's freed a
few lines below?
> > > err |= fdt_begin_node(fdt, map->name);
> > > err |= fdt_property_string(fdt, "compatible", RESERVE_MEM_KHO_NODE_COMPATIBLE);
> > > err |= fdt_property(fdt, "start", &map->start, sizeof(map->start));
> >
> > if (err)
> > goto err_unpreserve;
> >
> > and drop !err from the loop condition.
>
> That is going to miss one 'nr_preserved++' . We cannot do that, we
> could move it to the beginning of the loop, but I prefer keeping err
> right in the condition.
I very much dislike the error handling after this patch. From a single
if (err)
put_page()
it grew into a complex beast with special variables just for the sake of
it.
What I'd like to see is something like
err_unpreserve_fdt:
kho_unpreserve_folio(page_folio(fdt_page));
err_unpreserve_mems:
for (unsigned int i = 0; i < nr_preserved; i++) {
/* unpreserve mem[i] */
}
err_free_fdt:
put_page(fdt_page);
return err;
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2025-10-27 6:58 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-24 16:09 [PATCH v8 0/8] liveupdate: Rework KHO for in-kernel users Pasha Tatashin
2025-10-24 16:09 ` [PATCH v8 1/8] kho: allow to drive kho from within kernel Pasha Tatashin
2025-10-24 16:09 ` [PATCH v8 2/8] kho: make debugfs interface optional Pasha Tatashin
2025-10-24 16:09 ` [PATCH v8 3/8] kho: drop notifiers Pasha Tatashin
2025-10-24 16:43 ` Pratyush Yadav
2025-10-26 16:23 ` Mike Rapoport
2025-10-24 16:09 ` [PATCH v8 4/8] kho: add interfaces to unpreserve folios and page ranges Pasha Tatashin
2025-10-24 16:09 ` [PATCH v8 5/8] kho: don't unpreserve memory during abort Pasha Tatashin
2025-10-24 16:33 ` Pratyush Yadav
2025-10-24 16:10 ` [PATCH v8 6/8] liveupdate: kho: move to kernel/liveupdate Pasha Tatashin
2025-10-24 16:10 ` [PATCH v8 7/8] liveupdate: kho: move kho debugfs directory to liveupdate Pasha Tatashin
2025-10-26 16:32 ` Mike Rapoport
2025-10-26 16:47 ` Andrew Morton
2025-10-24 16:10 ` [PATCH v8 8/8] memblock: Unpreserve memory in case of error Pasha Tatashin
2025-10-24 16:43 ` Pratyush Yadav
2025-10-26 16:29 ` Mike Rapoport
2025-10-26 17:41 ` Pasha Tatashin
2025-10-27 6:58 ` Mike Rapoport [this message]
2025-10-27 6:56 ` Mike Rapoport
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=aP8YADj4ha3trjJn@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=corbet@lwn.net \
--cc=graf@amazon.com \
--cc=jgg@ziepe.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=masahiroy@kernel.org \
--cc=ojeda@kernel.org \
--cc=pasha.tatashin@soleen.com \
--cc=pratyush@kernel.org \
--cc=rdunlap@infradead.org \
--cc=tj@kernel.org \
/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.