* [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