Re: [PATCH v2 0/5] treewide: remove unreachable memblock_reserve() return value checks in early boot

Mike Rapoport <[email protected]> Tue, 7 Jul 2026 16:40:25 +0300
Newsgroups org.kernel.vger.linux-efi,org.kernel.vger.linux-kernel,org.kernel.vger.linux-sh,org.kvack.linux-mm,org.ozlabs.lists.linuxppc-dev
Message-ID <[email protected]>
On Tue, Jul 07, 2026 at 10:24:09PM +0900, Sang-Heon Jeon wrote:
> Hi Mike,
> 
> On Tue, Jul 7, 2026 at 3:17 PM Mike Rapoport <[email protected]> wrote:
> >
> > Hi Sang-Heon,
> >
> > On Tue, Jul 07, 2026 at 01:37:48AM +0900, Sang-Heon Jeon wrote:
> > > memblock_reserve() can only return an error after memblock_allow_resize()
> > > has been called. Before that it either succeeds or panics, never returning
> > > an error.
> > >
> > > Before memblock_allow_resize() is called, the return value checks of
> > > memblock_reserve() are unreachable and can be removed.
> >
> > I'd rather keep these checks.
> >
> > Removing them relies on internal details of memblock_reserve() implementation
> > and the existing event sequence. If the code would move around relying on
> > panic in memblock_reserve() may not be correct.
> >
> > And the few bytes and cycles the change saves do not worth the churn.
> 
> Makes sense to me.
> 
> But most early boot callers of memblock_reserve() don't check the
> return value, so I thought we already rely on its internal behavior
> anyway. So the few remaining checks just looked a bit inconsistent to
> me.

In reality it's very unlikely for memblock_reserve() to fail, especially
after resize is allowed. 
And if it does fail, the system would trip on a memory error, usually
sooner than later.

> Would you still prefer to keep these checks? If so, I'm fine with
> dropping this patch series. It's not a big deal :)

Let's keep the checks as they are now.
 
> Best Regards,
> Sang-Heon Jeon

-- 
Sincerely yours,
Mike.