From: Baoquan He <bhe@redhat.com>
To: Jiri Slaby <jirislaby@kernel.org>
Cc: linux-kernel@vger.kernel.org, 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: Re: kexec verbose dumps with 6.8 [was: [PATCH v4 1/7] kexec_file: add kexec_file flag to control debug printing]
Date: Wed, 13 Mar 2024 08:48:44 +0800 [thread overview]
Message-ID: <ZfD37AlznCXJ6P54@MiWiFi-R3L-srv> (raw)
In-Reply-To: <4c775fca-5def-4a2d-8437-7130b02722a2@kernel.org>
Hi Jiri,
On 03/12/24 at 10:58am, Jiri Slaby wrote:
> On 13. 12. 23, 6:57, Baoquan He wrote:
... snip...
> > --- 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.
It dumped always too with pr_debug() before, I just add a switch to
control it's pr_info() or pr_debug().
>
> 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)
On which arch are you seeing this? There should be one line above these
range printing to tell what they are, like:
E820 memmap:
0000000000000000-000000000009a3ff (1)
000000000009a400-000000000009ffff (2)
00000000000e0000-00000000000fffff (2)
0000000000100000-000000006ff83fff (1)
000000006ff84000-000000007ac50fff (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?
Right. Before this patch, those pr_debug() were already there. You need
enable them to print out like add '#define DEBUG' in *.c file, or enable
the dynamic debugging of the file or function. With this patch applied,
you only need specify '-d' when you execute kexec command with
kexec_file load interface, like:
kexec -s -l -d /boot/vmlinuz-xxxx.img --initrd xxx.img --reuse-cmdline
For kexec_file load, it is not logging if not specifying '-d', unless
you take way to make pr_debug() work in that file.
>
> Can this be redesigned, please?
Sure, after making clear what's going on with this, I will try.
>
> 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?
Joe suggested this during v1 reviewing:
https://lore.kernel.org/all/1e7863ec4e4ab10b84fd0e64f30f8464d2e484a3.camel@perches.com/T/#u
>
> ...
> > --- 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?
Yeah, kexec_file_dbg_print records if '-d' is specified when 'kexec'
command executed. Anything wrong with the global flag?
Thanks
Baoquan
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Jiri Slaby <jirislaby@kernel.org>
Cc: linux-kernel@vger.kernel.org, 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: Re: kexec verbose dumps with 6.8 [was: [PATCH v4 1/7] kexec_file: add kexec_file flag to control debug printing]
Date: Wed, 13 Mar 2024 08:48:44 +0800 [thread overview]
Message-ID: <ZfD37AlznCXJ6P54@MiWiFi-R3L-srv> (raw)
In-Reply-To: <4c775fca-5def-4a2d-8437-7130b02722a2@kernel.org>
Hi Jiri,
On 03/12/24 at 10:58am, Jiri Slaby wrote:
> On 13. 12. 23, 6:57, Baoquan He wrote:
... snip...
> > --- 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.
It dumped always too with pr_debug() before, I just add a switch to
control it's pr_info() or pr_debug().
>
> 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)
On which arch are you seeing this? There should be one line above these
range printing to tell what they are, like:
E820 memmap:
0000000000000000-000000000009a3ff (1)
000000000009a400-000000000009ffff (2)
00000000000e0000-00000000000fffff (2)
0000000000100000-000000006ff83fff (1)
000000006ff84000-000000007ac50fff (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?
Right. Before this patch, those pr_debug() were already there. You need
enable them to print out like add '#define DEBUG' in *.c file, or enable
the dynamic debugging of the file or function. With this patch applied,
you only need specify '-d' when you execute kexec command with
kexec_file load interface, like:
kexec -s -l -d /boot/vmlinuz-xxxx.img --initrd xxx.img --reuse-cmdline
For kexec_file load, it is not logging if not specifying '-d', unless
you take way to make pr_debug() work in that file.
>
> Can this be redesigned, please?
Sure, after making clear what's going on with this, I will try.
>
> 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?
Joe suggested this during v1 reviewing:
https://lore.kernel.org/all/1e7863ec4e4ab10b84fd0e64f30f8464d2e484a3.camel@perches.com/T/#u
>
> ...
> > --- 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?
Yeah, kexec_file_dbg_print records if '-d' is specified when 'kexec'
command executed. Anything wrong with the global flag?
Thanks
Baoquan
WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Jiri Slaby <jirislaby@kernel.org>
Cc: linux-kernel@vger.kernel.org, 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: Re: kexec verbose dumps with 6.8 [was: [PATCH v4 1/7] kexec_file: add kexec_file flag to control debug printing]
Date: Wed, 13 Mar 2024 08:48:44 +0800 [thread overview]
Message-ID: <ZfD37AlznCXJ6P54@MiWiFi-R3L-srv> (raw)
In-Reply-To: <4c775fca-5def-4a2d-8437-7130b02722a2@kernel.org>
Hi Jiri,
On 03/12/24 at 10:58am, Jiri Slaby wrote:
> On 13. 12. 23, 6:57, Baoquan He wrote:
... snip...
> > --- 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.
It dumped always too with pr_debug() before, I just add a switch to
control it's pr_info() or pr_debug().
>
> 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)
On which arch are you seeing this? There should be one line above these
range printing to tell what they are, like:
E820 memmap:
0000000000000000-000000000009a3ff (1)
000000000009a400-000000000009ffff (2)
00000000000e0000-00000000000fffff (2)
0000000000100000-000000006ff83fff (1)
000000006ff84000-000000007ac50fff (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?
Right. Before this patch, those pr_debug() were already there. You need
enable them to print out like add '#define DEBUG' in *.c file, or enable
the dynamic debugging of the file or function. With this patch applied,
you only need specify '-d' when you execute kexec command with
kexec_file load interface, like:
kexec -s -l -d /boot/vmlinuz-xxxx.img --initrd xxx.img --reuse-cmdline
For kexec_file load, it is not logging if not specifying '-d', unless
you take way to make pr_debug() work in that file.
>
> Can this be redesigned, please?
Sure, after making clear what's going on with this, I will try.
>
> 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?
Joe suggested this during v1 reviewing:
https://lore.kernel.org/all/1e7863ec4e4ab10b84fd0e64f30f8464d2e484a3.camel@perches.com/T/#u
>
> ...
> > --- 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?
Yeah, kexec_file_dbg_print records if '-d' is specified when 'kexec'
command executed. Anything wrong with the global flag?
Thanks
Baoquan
_______________________________________________
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: Baoquan He <bhe@redhat.com>
To: Jiri Slaby <jirislaby@kernel.org>
Cc: linux-parisc@vger.kernel.org, x86@kernel.org,
kexec@lists.infradead.org, linux-kernel@vger.kernel.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: Re: kexec verbose dumps with 6.8 [was: [PATCH v4 1/7] kexec_file: add kexec_file flag to control debug printing]
Date: Wed, 13 Mar 2024 08:48:44 +0800 [thread overview]
Message-ID: <ZfD37AlznCXJ6P54@MiWiFi-R3L-srv> (raw)
In-Reply-To: <4c775fca-5def-4a2d-8437-7130b02722a2@kernel.org>
Hi Jiri,
On 03/12/24 at 10:58am, Jiri Slaby wrote:
> On 13. 12. 23, 6:57, Baoquan He wrote:
... snip...
> > --- 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.
It dumped always too with pr_debug() before, I just add a switch to
control it's pr_info() or pr_debug().
>
> 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)
On which arch are you seeing this? There should be one line above these
range printing to tell what they are, like:
E820 memmap:
0000000000000000-000000000009a3ff (1)
000000000009a400-000000000009ffff (2)
00000000000e0000-00000000000fffff (2)
0000000000100000-000000006ff83fff (1)
000000006ff84000-000000007ac50fff (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?
Right. Before this patch, those pr_debug() were already there. You need
enable them to print out like add '#define DEBUG' in *.c file, or enable
the dynamic debugging of the file or function. With this patch applied,
you only need specify '-d' when you execute kexec command with
kexec_file load interface, like:
kexec -s -l -d /boot/vmlinuz-xxxx.img --initrd xxx.img --reuse-cmdline
For kexec_file load, it is not logging if not specifying '-d', unless
you take way to make pr_debug() work in that file.
>
> Can this be redesigned, please?
Sure, after making clear what's going on with this, I will try.
>
> 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?
Joe suggested this during v1 reviewing:
https://lore.kernel.org/all/1e7863ec4e4ab10b84fd0e64f30f8464d2e484a3.camel@perches.com/T/#u
>
> ...
> > --- 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?
Yeah, kexec_file_dbg_print records if '-d' is specified when 'kexec'
command executed. Anything wrong with the global flag?
Thanks
Baoquan
WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Jiri Slaby <jirislaby@kernel.org>
Cc: linux-kernel@vger.kernel.org, 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: Re: kexec verbose dumps with 6.8 [was: [PATCH v4 1/7] kexec_file: add kexec_file flag to control debug printing]
Date: Wed, 13 Mar 2024 08:48:44 +0800 [thread overview]
Message-ID: <ZfD37AlznCXJ6P54@MiWiFi-R3L-srv> (raw)
In-Reply-To: <4c775fca-5def-4a2d-8437-7130b02722a2@kernel.org>
Hi Jiri,
On 03/12/24 at 10:58am, Jiri Slaby wrote:
> On 13. 12. 23, 6:57, Baoquan He wrote:
... snip...
> > --- 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.
It dumped always too with pr_debug() before, I just add a switch to
control it's pr_info() or pr_debug().
>
> 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)
On which arch are you seeing this? There should be one line above these
range printing to tell what they are, like:
E820 memmap:
0000000000000000-000000000009a3ff (1)
000000000009a400-000000000009ffff (2)
00000000000e0000-00000000000fffff (2)
0000000000100000-000000006ff83fff (1)
000000006ff84000-000000007ac50fff (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?
Right. Before this patch, those pr_debug() were already there. You need
enable them to print out like add '#define DEBUG' in *.c file, or enable
the dynamic debugging of the file or function. With this patch applied,
you only need specify '-d' when you execute kexec command with
kexec_file load interface, like:
kexec -s -l -d /boot/vmlinuz-xxxx.img --initrd xxx.img --reuse-cmdline
For kexec_file load, it is not logging if not specifying '-d', unless
you take way to make pr_debug() work in that file.
>
> Can this be redesigned, please?
Sure, after making clear what's going on with this, I will try.
>
> 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?
Joe suggested this during v1 reviewing:
https://lore.kernel.org/all/1e7863ec4e4ab10b84fd0e64f30f8464d2e484a3.camel@perches.com/T/#u
>
> ...
> > --- 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?
Yeah, kexec_file_dbg_print records if '-d' is specified when 'kexec'
command executed. Anything wrong with the global flag?
Thanks
Baoquan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-03-13 0:48 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 ` 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-12 9:58 ` Jiri Slaby
2024-03-13 0:48 ` Baoquan He [this message]
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=ZfD37AlznCXJ6P54@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=conor@kernel.org \
--cc=jirislaby@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.