lkml.org 
[lkml]   [2019]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] initramfs: forcing panic when kstrdup failed
On Tue, 10 Dec 2019 09:15:54 +0100 Geert Uytterhoeven <geert@linux-m68k.org> 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.

\
 
 \ /
  Last update: 2019-12-11 01:52    [W:0.247 / U:0.292 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site