On Tue, 2023-12-19 at 12:22 +0800, Baoquan He wrote:
> Add Andrew to CC as Andrew helps to pick kexec/kdump patches.
Ah, thanks, I didn't realise that Andrew pulls in the kexec patches.
>
> On 12/13/23 at 08:40am, James Gowans wrote:
> ..
> > This has been tested by doing a kexec on x86_64
When an error is detected, use pr_err() instead of kexec_dprintk() to
output log message.
In addition, remove the unnecessary return from set_page_address().
Signed-off-by: Yuntao Wang
---
arch/x86/kernel/kexec-bzimage64.c | 2 +-
mm/highmem.c | 2 --
2 files changed, 1
On 12/18/23 at 11:40am, Pingfan Liu wrote:
> From: Pingfan Liu
>
> The default size reserved for crashkernel=,low is decided by the macro
> DEFAULT_CRASH_KERNEL_LOW_SIZE, which is based on arch.
>
> Signed-off-by: Pingfan Liu
> Cc: Baoquan He
> Cc: Dave Young
> To: kexec@lists.infradead.org
On Tue, 19 Dec 2023 11:50:32 +0800, fuqiang wang
wrote:
> 在 2023/12/19 10:47, Yuntao Wang 写道:
>
> > Hi fuqiang,
> >
> > Yesterday, I posted two patches that happen to address the bugs you an
> > Baoquan
> > are currently discussing here, I wasn't aware that you both were also
> > working
> >
On Tue, 19 Dec 2023 11:32:02 +0800, Baoquan He wrote:
> Hi Yuntao,
>
> On 12/19/23 at 10:02am, Yuntao Wang wrote:
> > On Mon, 18 Dec 2023 09:29:02 -0800, Andrew Morton
> > wrote:
> >
> > > On Mon, 18 Dec 2023 16:19:15 +0800 Yuntao Wang wrote:
> > >
> > > > mem->nr_ranges represents the
Add Andrew to CC as Andrew helps to pick kexec/kdump patches.
On 12/13/23 at 08:40am, James Gowans wrote:
..
> This has been tested by doing a kexec on x86_64 and aarch64.
Hi James,
Thanks for this great patch. My colleagues have opened bug in rhel to
track this and try to veryfy this
在 2023/12/19 10:47, Yuntao Wang 写道:
Hi fuqiang,
Yesterday, I posted two patches that happen to address the bugs you an Baoquan
are currently discussing here, I wasn't aware that you both were also working
on fixing these issues.
Baoquan suggested I talk to you about it.
If you're interested,
Hi Yuntao,
On 12/19/23 at 10:02am, Yuntao Wang wrote:
> On Mon, 18 Dec 2023 09:29:02 -0800, Andrew Morton
> wrote:
>
> > On Mon, 18 Dec 2023 16:19:15 +0800 Yuntao Wang wrote:
> >
> > > mem->nr_ranges represents the current number of elements stored in
> > > the mem->ranges array, and
Hi fuqiang,
Yesterday, I posted two patches that happen to address the bugs you an Baoquan
are currently discussing here, I wasn't aware that you both were also working
on fixing these issues.
Baoquan suggested I talk to you about it.
If you're interested, you can take a look at my patches and
Hi fuqiang,
Yesterday, I posted two patches that happen to address the bugs you an Baoquan
are currently discussing here, I wasn't aware that you both were also working
on fixing these issues.
Baoquan suggested I talk to you about it.
If you're interested, you can take a look at my patches and
On Mon, 18 Dec 2023 09:29:02 -0800, Andrew Morton
wrote:
> On Mon, 18 Dec 2023 16:19:15 +0800 Yuntao Wang wrote:
>
> > mem->nr_ranges represents the current number of elements stored in
> > the mem->ranges array, and mem->max_nr_ranges represents the maximum number
> > of elements that the
Hey Rob!
On 14.12.23 23:36, Rob Herring wrote:
On Wed, Dec 13, 2023 at 12:04:43AM +, Alexander Graf wrote:
We now have all bits in place to support KHO kexecs. This patch adds
awareness of KHO in the kexec file as well as boot path for arm64 and
adds the respective kconfig option to the
On Sun, 17 Dec 2023 11:35:28 +0800 Yuntao Wang wrote:
> When an error is detected, use pr_err() instead of pr_debug() to output
> log message.
>
> In addition, remove the unnecessary return from set_page_address().
>
> ...
>
> --- a/arch/x86/kernel/kexec-bzimage64.c
> +++
On Mon, 18 Dec 2023 16:19:15 +0800 Yuntao Wang wrote:
> mem->nr_ranges represents the current number of elements stored in
> the mem->ranges array, and mem->max_nr_ranges represents the maximum number
> of elements that the mem->ranges array can hold. Therefore, the correct
> array out-of-bounds
Hi all,
I am planning to release kexec-tools v2.0.28 in the next two weeks
to roughly coincide with the release of the v6.7 kernel.
I would like to ask interested parties to send any patches they would like
included in v2.0.28 within one week so they can be considered for inclusion
in an rc
On Mon 18-12-23 13:23:22, Pingfan Liu wrote:
> From: Pingfan Liu
>
>
> First of all, this series is only for proof of concept. It only passes
> compilation.
>
> For years, CMA is proposed to be used as crashkernel reserved memory.
> But DIO prevent us to follow it since DMA may be in-flight
Hi Yuntao,
On 12/18/23 at 04:19pm, Yuntao Wang wrote:
> This series tries to fix the potential cmem->ranges array overflow.
This series looks good to me. While you'd better talk to fuqiang to ask
if he wants to post these or wants to give up. He posted patch to raise
the potention issue and I
Hi Eric,
On Wed, 2023-12-13 at 10:39 -0600, Eric W. Biederman wrote:
>
> James Gowans writes:
>
> > syscore_shutdown() runs driver and module callbacks to get the system
> > into a state where it can be correctly shut down. In commit
> > 6f389a8f1dd2 ("PM / reboot: call syscore_shutdown()
在 2023/12/14 18:29, Baoquan He 写道:
On 11/30/23 at 09:20pm, fuqiang wang wrote:
On 2023/11/30 15:44, Baoquan He wrote:
On 11/27/23 at 10:56am, fuqiang wang wrote:
When the split happened, judge whether mem->nr_ranges is equal to
mem->max_nr_ranges. If it is true, return -ENOMEM.
The
mem->nr_ranges represents the current number of elements stored in
the mem->ranges array, and mem->max_nr_ranges represents the maximum number
of elements that the mem->ranges array can hold. Therefore, the correct
array out-of-bounds check should be mem->nr_ranges >= mem->max_nr_ranges.
This series tries to fix the potential cmem->ranges array overflow.
Yuntao Wang (2):
x86/crash: fix potential cmem->ranges array overflow
crash_core: fix out-of-bounds access check in
crash_exclude_mem_range()
arch/x86/kernel/crash.c | 9 +
kernel/crash_core.c | 2 +-
2
The max_nr_ranges field of cmem allocated in crash_setup_memmap_entries()
is not initialized, its default value is 0.
When elfcorehdr is allocated from the middle of crashk_res due to any
potential reason, that is, `image->elf_load_addr > crashk_res.start &&
image->elf_load_addr +
22 matches
Mail list logo
