Re: [PATCH] initramfs: forcing panic when kstrdup failed

[Andrew Morton]

On Tue, 10 Dec 2019 09:15:54 +0100 Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote:

> > --- a/init/initramfs.c
> > +++ b/init/initramfs.c
> > @@ -125,6 +125,8 @@ static void __init dir_add(const char *name, time64_t mtime)
> >                 panic("can't allocate dir_entry buffer");
> >         INIT_LIST_HEAD(&de->list);
> >         de->name = kstrdup(name, GFP_KERNEL);
> > +       if (!de->name)
> > +               panic("can't allocate dir_entry.name buffer");
> >         de->mtime = mtime;
> >         list_add(&de->list, &dir_list);
> >  }
> > @@ -340,6 +342,8 @@ static int __init do_name(void)
> >                                 if (body_len)
> >                                         ksys_ftruncate(wfd, body_len);
> >                                 vcollected = kstrdup(collected, GFP_KERNEL);
> > +                               if (!vcollected)
> > +                                       panic("can not allocate vcollected buffer.");
> >                                 state = CopyFile;
> >                         }
> >                 }
> 
> Do we really need to add more messages for out-of-memory conditions?
> The trend is to remove the printing of those messages, as the memory
> allocation subsystem will have printed a backtrace already anyway.

Yup.  And we traditionally assume that memory allocations won't fail at
init time anyway.  The reasoning being that the system is so enormously
messed up that the problem is both unrecoverable and very obvious.