On Thu, Dec 06, 2018 at 07:08:26PM +0100, Sam Ravnborg wrote:
> On Mon, Dec 03, 2018 at 06:49:21PM +0200, Mike Rapoport wrote:
> > On Mon, Dec 03, 2018 at 05:29:08PM +0100, Sam Ravnborg wrote:
> > > Hi Mike.
> > >
> > > > index c37955d..2a17665 100644
> > > > --- a/arch/sparc/kernel/prom_64.c
> > > > +++ b/arch/sparc/kernel/prom_64.c
> > > > @@ -34,16 +34,13 @@
> > > >
> > > > void * __init prom_early_alloc(unsigned long size)
> > > > {
> > > > - unsigned long paddr = memblock_phys_alloc(size, SMP_CACHE_BYTES);
> > > > - void *ret;
> > > > + void *ret = memblock_alloc(size, SMP_CACHE_BYTES);
> > > >
> > > > - if (!paddr) {
> > > > + if (!ret) {
> > > > prom_printf("prom_early_alloc(%lu) failed\n", size);
> > > > prom_halt();
> > > > }
> > > >
> > > > - ret = __va(paddr);
> > > > - memset(ret, 0, size);
> > > > prom_early_allocated += size;
> > > >
> > > > return ret;
> > >
> > > memblock_alloc() calls memblock_alloc_try_nid().
> > > And if allocation fails then memblock_alloc_try_nid() calls panic().
> > > So will we ever hit the prom_halt() code?
> >
> > memblock_phys_alloc_try_nid() also calls panic if an allocation fails. So
> > in either case we never reach prom_halt() code.
>
> So we have code here we never reach - not nice.
> If the idea is to avoid relying on the panic inside memblock_alloc() then
> maybe replace it with a variant that do not call panic?
> To make it clear what happens.
My plan is to completely remove memblock variants that call panic() and
make the callers check the return value.
I've started to work on it, but with the holidays it progresses slower than
I'd like to.
Since the code here was unreachable for several year, a few more weeks
won't make real difference so I'd prefer to keep the variant with panic()
for now.
> Sam
>
--
Sincerely yours,
Mike.
