Re: [RFC PATCH 1/2] kexec: do not place the next kernel in a fixed-address CMA area

[Mike Rapoport]

On Fri, Oct 30, 2026 at 01:22:50PM +0530, Pandey, Radhey Shyam wrote:
> On 10/29/2026 6:41 PM, Pratyush Yadav wrote:
> > On Thu, Oct 29 2026, Mike Rapoport wrote:
> > > On Wed, Oct 28, 2026 at 03:03:16PM +0100, Pratyush Yadav wrote:
> > > > On Wed, Oct 14 2026, Radhey Shyam Pandey wrote:
> > > > > @@ -304,6 +317,7 @@ int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
> > > > >   	cma->ranges[0].count = cma->count;
> > > > >   	cma->nranges = 1;
> > > > >   	cma->nid = NUMA_NO_NODE;
> > > > > +	set_bit(CMA_FIXED_BASE, &cma->flags);
> > > > >   	*res_cma = cma;
> > > > > @@ -517,6 +531,8 @@ static int __init __cma_declare_contiguous_nid(phys_addr_t *basep,
> > > > >   	}
> > > > >   	(*res_cma)->nid = nid;
> > > > > +	if (!fixed)
> > > > > +		clear_bit(CMA_FIXED_BASE, &(*res_cma)->flags);
> > > > 
> > > > Nit: This reads a bit odd. cma_init_reserved_mem() sets the fixed base
> > > > and then you clear it later. Wouldn't it be better to just pass the
> > > > fixed boolean to cma_init_reserved_mem()?
> > > 
> > > Actually, we shouldn't expose cma_init_reserved_mem() at all.
> > > 
> > > The current callers of cma_init_reserved_mem() should be switched to
> > > cma_declare_contiguous_nid() that does sanity checks before calling
> > > cma_init_reserved_mem().
> 
> Thanks Pratyush and Mike for the review.
> 
> The switch from cma_init_reserved_mem() to cma_declare_contiguous_nid()
> looks like a broader CMA refactoring and requires additional changes to work
> correctly.

Hmm, you are right.

How about we invert the flag meaning?
Than cma_declare_contiguous_* will set it where appropriate and we won't
have the weirdness Pratyush pointed out.

And Radhey, please, make your LLM to spill more concise and to the point
text and teach it to trim emails ;-)

> Thanks,
> Radhey
> 

-- 
Sincerely yours,
Mike.