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.