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 [off-list ref] wrote:

quoted

Hi Sang-Heon,

On Tue, Jul 07, 2026 at 01:37:48AM +0900, Sang-Heon Jeon wrote:

quoted

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.