public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] initramfs: Panic with memory information
@ 2021-01-14 23:15 Florian Fainelli
  2021-01-17 21:33 ` Andrew Morton
  0 siblings, 1 reply; 3+ messages in thread
From: Florian Fainelli @ 2021-01-14 23:15 UTC (permalink / raw)
  To: linux-kernel
  Cc: opendmb, Florian Fainelli, Barret Rhoden, Arnd Bergmann,
	Andrew Morton

On systems with large amounts of reserved memory we may fail to
successfully complete unpack_to_rootfs() and be left with:

 Kernel panic - not syncing: write error

this is not too helpful to understand what happened, so let's wrap the
panic() calls with a surrounding show_mem() such that we have a chance
of understanding the memory conditions leading to these allocation
failures.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 init/initramfs.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/init/initramfs.c b/init/initramfs.c
index 55b74d7e5260..9dafda6a401b 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -11,6 +11,7 @@
 #include <linux/utime.h>
 #include <linux/file.h>
 #include <linux/memblock.h>
+#include <linux/mm.h>
 #include <linux/namei.h>
 #include <linux/init_syscalls.h>
 
@@ -45,6 +46,11 @@ static void __init error(char *x)
 		message = x;
 }
 
+#define panic_show_mem(...) {	\
+	show_mem(0, NULL);	\
+	panic(__VA_ARGS__);	\
+}
+
 /* link hash */
 
 #define N_ALIGN(len) ((((len) + 1) & ~3) + 2)
@@ -80,7 +86,7 @@ static char __init *find_link(int major, int minor, int ino,
 	}
 	q = kmalloc(sizeof(struct hash), GFP_KERNEL);
 	if (!q)
-		panic("can't allocate link hash entry");
+		panic_show_mem("can't allocate link hash entry");
 	q->major = major;
 	q->minor = minor;
 	q->ino = ino;
@@ -125,7 +131,7 @@ static void __init dir_add(const char *name, time64_t mtime)
 {
 	struct dir_entry *de = kmalloc(sizeof(struct dir_entry), GFP_KERNEL);
 	if (!de)
-		panic("can't allocate dir_entry buffer");
+		panic_show_mem("can't allocate dir_entry buffer");
 	INIT_LIST_HEAD(&de->list);
 	de->name = kstrdup(name, GFP_KERNEL);
 	de->mtime = mtime;
@@ -460,7 +466,7 @@ static char * __init unpack_to_rootfs(char *buf, unsigned long len)
 	name_buf = kmalloc(N_ALIGN(PATH_MAX), GFP_KERNEL);
 
 	if (!header_buf || !symlink_buf || !name_buf)
-		panic("can't allocate buffers");
+		panic_show_mem("can't allocate buffers");
 
 	state = Start;
 	this_header = 0;
@@ -607,7 +613,7 @@ static int __init populate_rootfs(void)
 	/* Load the built in initramfs */
 	char *err = unpack_to_rootfs(__initramfs_start, __initramfs_size);
 	if (err)
-		panic("%s", err); /* Failed to decompress INTERNAL initramfs */
+		panic_show_mem("%s", err); /* Failed to decompress INTERNAL initramfs */
 
 	if (!initrd_start || IS_ENABLED(CONFIG_INITRAMFS_FORCE))
 		goto done;
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] initramfs: Panic with memory information
  2021-01-14 23:15 [PATCH] initramfs: Panic with memory information Florian Fainelli
@ 2021-01-17 21:33 ` Andrew Morton
  2021-01-18  3:09   ` Florian Fainelli
  0 siblings, 1 reply; 3+ messages in thread
From: Andrew Morton @ 2021-01-17 21:33 UTC (permalink / raw)
  To: Florian Fainelli; +Cc: linux-kernel, opendmb, Barret Rhoden, Arnd Bergmann

On Thu, 14 Jan 2021 15:15:16 -0800 Florian Fainelli <f.fainelli@gmail.com> wrote:

> On systems with large amounts of reserved memory we may fail to
> successfully complete unpack_to_rootfs() and be left with:
> 
>  Kernel panic - not syncing: write error
> 
> this is not too helpful to understand what happened, so let's wrap the
> panic() calls with a surrounding show_mem() such that we have a chance
> of understanding the memory conditions leading to these allocation
> failures.

Seems sensible.

> @@ -45,6 +46,11 @@ static void __init error(char *x)
>  		message = x;
>  }
>  
> +#define panic_show_mem(...) {	\
> +	show_mem(0, NULL);	\
> +	panic(__VA_ARGS__);	\
> +}
> +

But can we replace nasty macro with pleasing C code?

--- a/init/initramfs.c~initramfs-panic-with-memory-information-fix
+++ a/init/initramfs.c
@@ -46,9 +46,14 @@ static void __init error(char *x)
 		message = x;
 }
 
-#define panic_show_mem(...) {	\
-	show_mem(0, NULL);	\
-	panic(__VA_ARGS__);	\
+static void panic_show_mem(const char *fmt, ...)
+{
+	va_list args;
+
+	show_mem(0, NULL);
+	va_start(args, fmt);
+	panic(fmt, args);
+	va_end(args);
 }
 
 /* link hash */
_


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] initramfs: Panic with memory information
  2021-01-17 21:33 ` Andrew Morton
@ 2021-01-18  3:09   ` Florian Fainelli
  0 siblings, 0 replies; 3+ messages in thread
From: Florian Fainelli @ 2021-01-18  3:09 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, opendmb, Barret Rhoden, Arnd Bergmann



On 1/17/2021 1:33 PM, Andrew Morton wrote:
> On Thu, 14 Jan 2021 15:15:16 -0800 Florian Fainelli <f.fainelli@gmail.com> wrote:
> 
>> On systems with large amounts of reserved memory we may fail to
>> successfully complete unpack_to_rootfs() and be left with:
>>
>>  Kernel panic - not syncing: write error
>>
>> this is not too helpful to understand what happened, so let's wrap the
>> panic() calls with a surrounding show_mem() such that we have a chance
>> of understanding the memory conditions leading to these allocation
>> failures.
> 
> Seems sensible.
> 
>> @@ -45,6 +46,11 @@ static void __init error(char *x)
>>  		message = x;
>>  }
>>  
>> +#define panic_show_mem(...) {	\
>> +	show_mem(0, NULL);	\
>> +	panic(__VA_ARGS__);	\
>> +}
>> +
> 
> But can we replace nasty macro with pleasing C code?

That works for me, would you like to squash this into my patch before
sending this to Linus?
-- 
Florian

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-01-18  3:10 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-01-14 23:15 [PATCH] initramfs: Panic with memory information Florian Fainelli
2021-01-17 21:33 ` Andrew Morton
2021-01-18  3:09   ` Florian Fainelli

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox