[PATCH] initramfs: forcing panic when kstrdup failed

[PATCH] initramfs: forcing panic when kstrdup failed

[zhanglin]

preventing further undefined behaviour when kstrdup failed.

Signed-off-by: zhanglin <zhang.lin16@zte.com.cn>
---
 init/initramfs.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/init/initramfs.c b/init/initramfs.c
index fca899622937..39a4fba48cc7 100644
--- 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;
 			}
 		}
-- 
2.17.1

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

[David Engraf]

On 10.12.19 at 03:48, zhanglin wrote:
> preventing further undefined behaviour when kstrdup failed.
> 
> Signed-off-by: zhanglin <zhang.lin16@zte.com.cn>
> ---
>   init/initramfs.c | 4 ++++
>   1 file changed, 4 insertions(+)
> 
> diff --git a/init/initramfs.c b/init/initramfs.c
> index fca899622937..39a4fba48cc7 100644
> --- 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.");

I would change the message to have the same naming as the other out of 
memory messages:

panic("can't allocate vcollected buffer");

Best regards
- David

>   				state = CopyFile;
>   			}
>   		}
> 

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

[Geert Uytterhoeven]

On Tue, Dec 10, 2019 at 3:47 AM zhanglin <zhang.lin16@zte.com.cn> wrote:
> preventing further undefined behaviour when kstrdup failed.
>
> Signed-off-by: zhanglin <zhang.lin16@zte.com.cn>

Thanks for your patch!

> --- 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.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Andrew Morton]

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.