From: Jiri Slaby <jirislaby@kernel.org>
To: Baoquan He <bhe@redhat.com>, linux-kernel@vger.kernel.org
Cc: kexec@lists.infradead.org, x86@kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-riscv@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
linux-parisc@vger.kernel.org, akpm@linux-foundation.org,
joe@perches.com, nathan@kernel.org, conor@kernel.org
Subject: kexec verbose dumps with 6.8 [was: [PATCH v4 1/7] kexec_file: add kexec_file flag to control debug printing]
Date: Tue, 12 Mar 2024 10:58:50 +0100 [thread overview]
Message-ID: <4c775fca-5def-4a2d-8437-7130b02722a2@kernel.org> (raw)
In-Reply-To: <20231213055747.61826-2-bhe@redhat.com>
On 13. 12. 23, 6:57, Baoquan He wrote:
> When specifying 'kexec -c -d', kexec_load interface will print loading
> information, e.g the regions where kernel/initrd/purgatory/cmdline
> are put, the memmap passed to 2nd kernel taken as system RAM ranges,
> and printing all contents of struct kexec_segment, etc. These are
> very helpful for analyzing or positioning what's happening when
> kexec/kdump itself failed. The debugging printing for kexec_load
> interface is made in user space utility kexec-tools.
>
> Whereas, with kexec_file_load interface, 'kexec -s -d' print nothing.
> Because kexec_file code is mostly implemented in kernel space, and the
> debugging printing functionality is missed. It's not convenient when
> debugging kexec/kdump loading and jumping with kexec_file_load
> interface.
>
> Now add KEXEC_FILE_DEBUG to kexec_file flag to control the debugging
> message printing. And add global variable kexec_file_dbg_print and
> macro kexec_dprintk() to facilitate the printing.
>
> This is a preparation, later kexec_dprintk() will be used to replace the
> existing pr_debug(). Once 'kexec -s -d' is specified, it will print out
> kexec/kdump loading information. If '-d' is not specified, it regresses
> to pr_debug().
>
> Signed-off-by: Baoquan He <bhe@redhat.com>
...
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
...
> @@ -500,6 +500,13 @@ static inline int crash_hotplug_memory_support(void) { return 0; }
> static inline unsigned int crash_get_elfcorehdr_size(void) { return 0; }
> #endif
>
> +extern bool kexec_file_dbg_print;
> +
> +#define kexec_dprintk(fmt, ...) \
> + printk("%s" fmt, \
> + kexec_file_dbg_print ? KERN_INFO : KERN_DEBUG, \
> + ##__VA_ARGS__)
This means you dump it _always_. Only with different levels.
And without any prefix whatsoever, so people see bloat like this in
their log now:
[ +0.000001] 0000000000001000-000000000009ffff (1)
[ +0.000002] 000000007f96d000-000000007f97efff (3)
[ +0.000002] 0000000000800000-0000000000807fff (4)
[ +0.000001] 000000000080b000-000000000080bfff (4)
[ +0.000002] 0000000000810000-00000000008fffff (4)
[ +0.000001] 000000007f97f000-000000007f9fefff (4)
[ +0.000001] 000000007ff00000-000000007fffffff (4)
[ +0.000002] 0000000000000000-0000000000000fff (2)
without actually knowing what that is.
There should be nothing logged if that is not asked for and especially
if kexec load went fine, right?
Can this be redesigned, please?
Actually what was wrong on the pr_debug()s? Can you simply turn them on
from the kernel when -d is passed to kexec instead of all this?
...
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -52,6 +52,8 @@ atomic_t __kexec_lock = ATOMIC_INIT(0);
> /* Flag to indicate we are going to kexec a new kernel */
> bool kexec_in_progress = false;
>
> +bool kexec_file_dbg_print;
Ugh, and a global flag for this?
thanks,
--
js
suse labs
WARNING: multiple messages have this Message-ID (diff)
From: Jiri Slaby <jirislaby@kernel.org>
To: Baoquan He <bhe@redhat.com>, linux-kernel@vger.kernel.org
Cc: kexec@lists.infradead.org, x86@kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-riscv@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
linux-parisc@vger.kernel.org, akpm@linux-foundation.org,
joe@perches.com, nathan@kernel.org, conor@kernel.org
Subject: kexec verbose dumps with 6.8 [was: [PATCH v4 1/7] kexec_file: add kexec_file flag to control debug printing]
Date: Tue, 12 Mar 2024 10:58:50 +0100 [thread overview]
Message-ID: <4c775fca-5def-4a2d-8437-7130b02722a2@kernel.org> (raw)
In-Reply-To: <20231213055747.61826-2-bhe@redhat.com>
On 13. 12. 23, 6:57, Baoquan He wrote:
> When specifying 'kexec -c -d', kexec_load interface will print loading
> information, e.g the regions where kernel/initrd/purgatory/cmdline
> are put, the memmap passed to 2nd kernel taken as system RAM ranges,
> and printing all contents of struct kexec_segment, etc. These are
> very helpful for analyzing or positioning what's happening when
> kexec/kdump itself failed. The debugging printing for kexec_load
> interface is made in user space utility kexec-tools.
>
> Whereas, with kexec_file_load interface, 'kexec -s -d' print nothing.
> Because kexec_file code is mostly implemented in kernel space, and the
> debugging printing functionality is missed. It's not convenient when
> debugging kexec/kdump loading and jumping with kexec_file_load
> interface.
>
> Now add KEXEC_FILE_DEBUG to kexec_file flag to control the debugging
> message printing. And add global variable kexec_file_dbg_print and
> macro kexec_dprintk() to facilitate the printing.
>
> This is a preparation, later kexec_dprintk() will be used to replace the
> existing pr_debug(). Once 'kexec -s -d' is specified, it will print out
> kexec/kdump loading information. If '-d' is not specified, it regresses
> to pr_debug().
>
> Signed-off-by: Baoquan He <bhe@redhat.com>
...
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
...
> @@ -500,6 +500,13 @@ static inline int crash_hotplug_memory_support(void) { return 0; }
> static inline unsigned int crash_get_elfcorehdr_size(void) { return 0; }
> #endif
>
> +extern bool kexec_file_dbg_print;
> +
> +#define kexec_dprintk(fmt, ...) \
> + printk("%s" fmt, \
> + kexec_file_dbg_print ? KERN_INFO : KERN_DEBUG, \
> + ##__VA_ARGS__)
This means you dump it _always_. Only with different levels.
And without any prefix whatsoever, so people see bloat like this in
their log now:
[ +0.000001] 0000000000001000-000000000009ffff (1)
[ +0.000002] 000000007f96d000-000000007f97efff (3)
[ +0.000002] 0000000000800000-0000000000807fff (4)
[ +0.000001] 000000000080b000-000000000080bfff (4)
[ +0.000002] 0000000000810000-00000000008fffff (4)
[ +0.000001] 000000007f97f000-000000007f9fefff (4)
[ +0.000001] 000000007ff00000-000000007fffffff (4)
[ +0.000002] 0000000000000000-0000000000000fff (2)
without actually knowing what that is.
There should be nothing logged if that is not asked for and especially
if kexec load went fine, right?
Can this be redesigned, please?
Actually what was wrong on the pr_debug()s? Can you simply turn them on
from the kernel when -d is passed to kexec instead of all this?
...
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -52,6 +52,8 @@ atomic_t __kexec_lock = ATOMIC_INIT(0);
> /* Flag to indicate we are going to kexec a new kernel */
> bool kexec_in_progress = false;
>
> +bool kexec_file_dbg_print;
Ugh, and a global flag for this?
thanks,
--
js
suse labs
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Jiri Slaby <jirislaby@kernel.org>
To: Baoquan He <bhe@redhat.com>, linux-kernel@vger.kernel.org
Cc: kexec@lists.infradead.org, x86@kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-riscv@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
linux-parisc@vger.kernel.org, akpm@linux-foundation.org,
joe@perches.com, nathan@kernel.org, conor@kernel.org
Subject: kexec verbose dumps with 6.8 [was: [PATCH v4 1/7] kexec_file: add kexec_file flag to control debug printing]
Date: Tue, 12 Mar 2024 10:58:50 +0100 [thread overview]
Message-ID: <4c775fca-5def-4a2d-8437-7130b02722a2@kernel.org> (raw)
In-Reply-To: <20231213055747.61826-2-bhe@redhat.com>
On 13. 12. 23, 6:57, Baoquan He wrote:
> When specifying 'kexec -c -d', kexec_load interface will print loading
> information, e.g the regions where kernel/initrd/purgatory/cmdline
> are put, the memmap passed to 2nd kernel taken as system RAM ranges,
> and printing all contents of struct kexec_segment, etc. These are
> very helpful for analyzing or positioning what's happening when
> kexec/kdump itself failed. The debugging printing for kexec_load
> interface is made in user space utility kexec-tools.
>
> Whereas, with kexec_file_load interface, 'kexec -s -d' print nothing.
> Because kexec_file code is mostly implemented in kernel space, and the
> debugging printing functionality is missed. It's not convenient when
> debugging kexec/kdump loading and jumping with kexec_file_load
> interface.
>
> Now add KEXEC_FILE_DEBUG to kexec_file flag to control the debugging
> message printing. And add global variable kexec_file_dbg_print and
> macro kexec_dprintk() to facilitate the printing.
>
> This is a preparation, later kexec_dprintk() will be used to replace the
> existing pr_debug(). Once 'kexec -s -d' is specified, it will print out
> kexec/kdump loading information. If '-d' is not specified, it regresses
> to pr_debug().
>
> Signed-off-by: Baoquan He <bhe@redhat.com>
...
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
...
> @@ -500,6 +500,13 @@ static inline int crash_hotplug_memory_support(void) { return 0; }
> static inline unsigned int crash_get_elfcorehdr_size(void) { return 0; }
> #endif
>
> +extern bool kexec_file_dbg_print;
> +
> +#define kexec_dprintk(fmt, ...) \
> + printk("%s" fmt, \
> + kexec_file_dbg_print ? KERN_INFO : KERN_DEBUG, \
> + ##__VA_ARGS__)
This means you dump it _always_. Only with different levels.
And without any prefix whatsoever, so people see bloat like this in
their log now:
[ +0.000001] 0000000000001000-000000000009ffff (1)
[ +0.000002] 000000007f96d000-000000007f97efff (3)
[ +0.000002] 0000000000800000-0000000000807fff (4)
[ +0.000001] 000000000080b000-000000000080bfff (4)
[ +0.000002] 0000000000810000-00000000008fffff (4)
[ +0.000001] 000000007f97f000-000000007f9fefff (4)
[ +0.000001] 000000007ff00000-000000007fffffff (4)
[ +0.000002] 0000000000000000-0000000000000fff (2)
without actually knowing what that is.
There should be nothing logged if that is not asked for and especially
if kexec load went fine, right?
Can this be redesigned, please?
Actually what was wrong on the pr_debug()s? Can you simply turn them on
from the kernel when -d is passed to kexec instead of all this?
...
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -52,6 +52,8 @@ atomic_t __kexec_lock = ATOMIC_INIT(0);
> /* Flag to indicate we are going to kexec a new kernel */
> bool kexec_in_progress = false;
>
> +bool kexec_file_dbg_print;
Ugh, and a global flag for this?
thanks,
--
js
suse labs
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Jiri Slaby <jirislaby@kernel.org>
To: Baoquan He <bhe@redhat.com>, linux-kernel@vger.kernel.org
Cc: kexec@lists.infradead.org, x86@kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-riscv@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
linux-parisc@vger.kernel.org, akpm@linux-foundation.org,
joe@perches.com, nathan@kernel.org, conor@kernel.org
Subject: kexec verbose dumps with 6.8 [was: [PATCH v4 1/7] kexec_file: add kexec_file flag to control debug printing]
Date: Tue, 12 Mar 2024 10:58:50 +0100 [thread overview]
Message-ID: <4c775fca-5def-4a2d-8437-7130b02722a2@kernel.org> (raw)
In-Reply-To: <20231213055747.61826-2-bhe@redhat.com>
On 13. 12. 23, 6:57, Baoquan He wrote:
> When specifying 'kexec -c -d', kexec_load interface will print loading
> information, e.g the regions where kernel/initrd/purgatory/cmdline
> are put, the memmap passed to 2nd kernel taken as system RAM ranges,
> and printing all contents of struct kexec_segment, etc. These are
> very helpful for analyzing or positioning what's happening when
> kexec/kdump itself failed. The debugging printing for kexec_load
> interface is made in user space utility kexec-tools.
>
> Whereas, with kexec_file_load interface, 'kexec -s -d' print nothing.
> Because kexec_file code is mostly implemented in kernel space, and the
> debugging printing functionality is missed. It's not convenient when
> debugging kexec/kdump loading and jumping with kexec_file_load
> interface.
>
> Now add KEXEC_FILE_DEBUG to kexec_file flag to control the debugging
> message printing. And add global variable kexec_file_dbg_print and
> macro kexec_dprintk() to facilitate the printing.
>
> This is a preparation, later kexec_dprintk() will be used to replace the
> existing pr_debug(). Once 'kexec -s -d' is specified, it will print out
> kexec/kdump loading information. If '-d' is not specified, it regresses
> to pr_debug().
>
> Signed-off-by: Baoquan He <bhe@redhat.com>
...
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
...
> @@ -500,6 +500,13 @@ static inline int crash_hotplug_memory_support(void) { return 0; }
> static inline unsigned int crash_get_elfcorehdr_size(void) { return 0; }
> #endif
>
> +extern bool kexec_file_dbg_print;
> +
> +#define kexec_dprintk(fmt, ...) \
> + printk("%s" fmt, \
> + kexec_file_dbg_print ? KERN_INFO : KERN_DEBUG, \
> + ##__VA_ARGS__)
This means you dump it _always_. Only with different levels.
And without any prefix whatsoever, so people see bloat like this in
their log now:
[ +0.000001] 0000000000001000-000000000009ffff (1)
[ +0.000002] 000000007f96d000-000000007f97efff (3)
[ +0.000002] 0000000000800000-0000000000807fff (4)
[ +0.000001] 000000000080b000-000000000080bfff (4)
[ +0.000002] 0000000000810000-00000000008fffff (4)
[ +0.000001] 000000007f97f000-000000007f9fefff (4)
[ +0.000001] 000000007ff00000-000000007fffffff (4)
[ +0.000002] 0000000000000000-0000000000000fff (2)
without actually knowing what that is.
There should be nothing logged if that is not asked for and especially
if kexec load went fine, right?
Can this be redesigned, please?
Actually what was wrong on the pr_debug()s? Can you simply turn them on
from the kernel when -d is passed to kexec instead of all this?
...
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -52,6 +52,8 @@ atomic_t __kexec_lock = ATOMIC_INIT(0);
> /* Flag to indicate we are going to kexec a new kernel */
> bool kexec_in_progress = false;
>
> +bool kexec_file_dbg_print;
Ugh, and a global flag for this?
thanks,
--
js
suse labs
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Jiri Slaby <jirislaby@kernel.org>
To: Baoquan He <bhe@redhat.com>, linux-kernel@vger.kernel.org
Cc: linux-parisc@vger.kernel.org, x86@kernel.org,
kexec@lists.infradead.org, conor@kernel.org, nathan@kernel.org,
joe@perches.com, linux-riscv@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org, akpm@linux-foundation.org,
linux-arm-kernel@lists.infradead.org
Subject: kexec verbose dumps with 6.8 [was: [PATCH v4 1/7] kexec_file: add kexec_file flag to control debug printing]
Date: Tue, 12 Mar 2024 10:58:50 +0100 [thread overview]
Message-ID: <4c775fca-5def-4a2d-8437-7130b02722a2@kernel.org> (raw)
In-Reply-To: <20231213055747.61826-2-bhe@redhat.com>
On 13. 12. 23, 6:57, Baoquan He wrote:
> When specifying 'kexec -c -d', kexec_load interface will print loading
> information, e.g the regions where kernel/initrd/purgatory/cmdline
> are put, the memmap passed to 2nd kernel taken as system RAM ranges,
> and printing all contents of struct kexec_segment, etc. These are
> very helpful for analyzing or positioning what's happening when
> kexec/kdump itself failed. The debugging printing for kexec_load
> interface is made in user space utility kexec-tools.
>
> Whereas, with kexec_file_load interface, 'kexec -s -d' print nothing.
> Because kexec_file code is mostly implemented in kernel space, and the
> debugging printing functionality is missed. It's not convenient when
> debugging kexec/kdump loading and jumping with kexec_file_load
> interface.
>
> Now add KEXEC_FILE_DEBUG to kexec_file flag to control the debugging
> message printing. And add global variable kexec_file_dbg_print and
> macro kexec_dprintk() to facilitate the printing.
>
> This is a preparation, later kexec_dprintk() will be used to replace the
> existing pr_debug(). Once 'kexec -s -d' is specified, it will print out
> kexec/kdump loading information. If '-d' is not specified, it regresses
> to pr_debug().
>
> Signed-off-by: Baoquan He <bhe@redhat.com>
...
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
...
> @@ -500,6 +500,13 @@ static inline int crash_hotplug_memory_support(void) { return 0; }
> static inline unsigned int crash_get_elfcorehdr_size(void) { return 0; }
> #endif
>
> +extern bool kexec_file_dbg_print;
> +
> +#define kexec_dprintk(fmt, ...) \
> + printk("%s" fmt, \
> + kexec_file_dbg_print ? KERN_INFO : KERN_DEBUG, \
> + ##__VA_ARGS__)
This means you dump it _always_. Only with different levels.
And without any prefix whatsoever, so people see bloat like this in
their log now:
[ +0.000001] 0000000000001000-000000000009ffff (1)
[ +0.000002] 000000007f96d000-000000007f97efff (3)
[ +0.000002] 0000000000800000-0000000000807fff (4)
[ +0.000001] 000000000080b000-000000000080bfff (4)
[ +0.000002] 0000000000810000-00000000008fffff (4)
[ +0.000001] 000000007f97f000-000000007f9fefff (4)
[ +0.000001] 000000007ff00000-000000007fffffff (4)
[ +0.000002] 0000000000000000-0000000000000fff (2)
without actually knowing what that is.
There should be nothing logged if that is not asked for and especially
if kexec load went fine, right?
Can this be redesigned, please?
Actually what was wrong on the pr_debug()s? Can you simply turn them on
from the kernel when -d is passed to kexec instead of all this?
...
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -52,6 +52,8 @@ atomic_t __kexec_lock = ATOMIC_INIT(0);
> /* Flag to indicate we are going to kexec a new kernel */
> bool kexec_in_progress = false;
>
> +bool kexec_file_dbg_print;
Ugh, and a global flag for this?
thanks,
--
js
suse labs
next prev parent reply other threads:[~2024-03-12 9:58 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-13 5:57 [PATCH v4 0/7] kexec_file: print out debugging message if required Baoquan He
2023-12-13 5:57 ` Baoquan He
2023-12-13 5:57 ` Baoquan He
2023-12-13 5:57 ` Baoquan He
2023-12-13 5:57 ` Baoquan He
2023-12-13 5:57 ` [PATCH v4 1/7] kexec_file: add kexec_file flag to control debug printing Baoquan He
2023-12-13 5:57 ` Baoquan He
2023-12-13 5:57 ` Baoquan He
2023-12-13 5:57 ` Baoquan He
2023-12-13 5:57 ` Baoquan He
2024-03-12 9:58 ` Jiri Slaby [this message]
2024-03-12 9:58 ` kexec verbose dumps with 6.8 [was: [PATCH v4 1/7] kexec_file: add kexec_file flag to control debug printing] Jiri Slaby
2024-03-12 9:58 ` Jiri Slaby
2024-03-12 9:58 ` Jiri Slaby
2024-03-12 9:58 ` Jiri Slaby
2024-03-13 0:48 ` Baoquan He
2024-03-13 0:48 ` Baoquan He
2024-03-13 0:48 ` Baoquan He
2024-03-13 0:48 ` Baoquan He
2024-03-13 0:48 ` Baoquan He
2024-03-13 5:58 ` Jiri Slaby
2024-03-13 5:58 ` Jiri Slaby
2024-03-13 5:58 ` Jiri Slaby
2024-03-13 5:58 ` Jiri Slaby
2024-03-13 5:58 ` Jiri Slaby
2024-03-13 7:10 ` Baoquan He
2024-03-13 7:10 ` Baoquan He
2024-03-13 7:10 ` Baoquan He
2024-03-13 7:10 ` Baoquan He
2024-03-13 7:10 ` Baoquan He
2023-12-13 5:57 ` [PATCH v4 2/7] kexec_file: print out debugging message if required Baoquan He
2023-12-13 5:57 ` Baoquan He
2023-12-13 5:57 ` Baoquan He
2023-12-13 5:57 ` Baoquan He
2023-12-13 5:57 ` Baoquan He
2023-12-13 5:57 ` [PATCH v4 3/7] kexec_file, x86: " Baoquan He
2023-12-13 5:57 ` Baoquan He
2023-12-13 5:57 ` Baoquan He
2023-12-13 5:57 ` Baoquan He
2023-12-13 5:57 ` Baoquan He
2023-12-13 5:57 ` [PATCH v4 4/7] kexec_file, arm64: " Baoquan He
2023-12-13 5:57 ` Baoquan He
2023-12-13 5:57 ` Baoquan He
2023-12-13 5:57 ` Baoquan He
2023-12-13 5:57 ` Baoquan He
2023-12-13 5:57 ` [PATCH v4 5/7] kexec_file, ricv: " Baoquan He
2023-12-13 5:57 ` Baoquan He
2023-12-13 5:57 ` Baoquan He
2023-12-13 5:57 ` Baoquan He
2023-12-13 5:57 ` Baoquan He
2023-12-19 14:44 ` Conor Dooley
2023-12-19 14:44 ` Conor Dooley
2023-12-19 14:44 ` Conor Dooley
2023-12-19 14:44 ` Conor Dooley
2023-12-19 14:44 ` Conor Dooley
2023-12-20 4:22 ` Baoquan He
2023-12-20 4:22 ` Baoquan He
2023-12-20 4:22 ` Baoquan He
2023-12-20 4:22 ` Baoquan He
2023-12-20 4:22 ` Baoquan He
2023-12-20 15:46 ` Andrew Morton
2023-12-20 15:46 ` Andrew Morton
2023-12-20 15:46 ` Andrew Morton
2023-12-20 15:46 ` Andrew Morton
2023-12-20 15:46 ` Andrew Morton
2023-12-20 23:30 ` Baoquan He
2023-12-20 23:30 ` Baoquan He
2023-12-20 23:30 ` Baoquan He
2023-12-20 23:30 ` Baoquan He
2023-12-20 23:30 ` Baoquan He
2023-12-13 5:57 ` [PATCH v4 6/7] kexec_file, power: " Baoquan He
2023-12-13 5:57 ` Baoquan He
2023-12-13 5:57 ` Baoquan He
2023-12-13 5:57 ` Baoquan He
2023-12-13 5:57 ` Baoquan He
2023-12-13 5:57 ` [PATCH v4 7/7] kexec_file, parisc: " Baoquan He
2023-12-13 5:57 ` Baoquan He
2023-12-13 5:57 ` Baoquan He
2023-12-13 5:57 ` Baoquan He
2023-12-13 5:57 ` Baoquan He
2024-01-20 21:09 ` [PATCH v4 0/7] kexec_file: " patchwork-bot+linux-riscv
2024-01-20 21:09 ` patchwork-bot+linux-riscv
2024-01-20 21:09 ` patchwork-bot+linux-riscv
2024-01-20 21:09 ` patchwork-bot+linux-riscv
2024-01-20 21:09 ` patchwork-bot+linux-riscv
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4c775fca-5def-4a2d-8437-7130b02722a2@kernel.org \
--to=jirislaby@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=conor@kernel.org \
--cc=joe@perches.com \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=nathan@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.