Re: [PATCH] kexec: should use uchunk for user buffer increasing

2024-02-03 Thread Baoquan He
On 01/30/24 at 06:18pm, yang.zhang wrote:
> From: "yang.zhang" 
> 
> Because of alignment requirement in kexec-tools, there is
> no problem for user buffer increasing when loading segments.
> But when coping, the step is uchunk, so we should use uchunk
> not mchunk.

In theory, ubytes is <= mbytes. So uchunk is always <= mchunk. If ubytes
is exhausted, while there's still remaining mbytes, then uchunk is 0,
there's still mchunk stepping forward. If I understand it correctly,
this is a good catch. Not sure if Eric has comment on this to confirm.

static int kimage_load_normal_segment(struct kimage *image,
 struct kexec_segment *segment)
{
..

ptr += maddr & ~PAGE_MASK;
mchunk = min_t(size_t, mbytes,
PAGE_SIZE - (maddr & ~PAGE_MASK));
uchunk = min(ubytes, mchunk);
..}

> 
> Signed-off-by: yang.zhang 
> ---
>  kernel/kexec_core.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index d08fc7b5db97..2b8354313c85 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -813,9 +813,9 @@ static int kimage_load_normal_segment(struct kimage 
> *image,
>   ubytes -= uchunk;
>   maddr  += mchunk;
>   if (image->file_mode)
> - kbuf += mchunk;
> + kbuf += uchunk;
>   else
> - buf += mchunk;
> + buf += uchunk;
>   mbytes -= mchunk;
>  
>   cond_resched();
> @@ -881,9 +881,9 @@ static int kimage_load_crash_segment(struct kimage *image,
>   ubytes -= uchunk;
>   maddr  += mchunk;
>   if (image->file_mode)
> - kbuf += mchunk;
> + kbuf += uchunk;
>   else
> - buf += mchunk;
> + buf += uchunk;
>   mbytes -= mchunk;
>  
>   cond_resched();
> -- 
> 2.34.1
> 
> 
> ___
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec


Re: [PATCH v2 00/14] Split crash out from kexec and clean up related config items

2024-02-03 Thread Baoquan He
On 02/02/24 at 10:53am, Hari Bathini wrote:
> Hi Baoquan,
> 
> On 19/01/24 8:22 pm, Baoquan He wrote:
> > Motivation:
> > =
> > Previously, LKP reported a building error. When investigating, it can't
> > be resolved reasonablly with the present messy kdump config items.
> > 
> >   https://lore.kernel.org/oe-kbuild-all/202312182200.ka7mzifq-...@intel.com/
> > 
> > The kdump (crash dumping) related config items could causes confusions:
> > 
> > Firstly,
> > ---
> > CRASH_CORE enables codes including
> >   - crashkernel reservation;
> >   - elfcorehdr updating;
> >   - vmcoreinfo exporting;
> >   - crash hotplug handling;
> > 
> > Now fadump of powerpc, kcore dynamic debugging and kdump all selects
> > CRASH_CORE, while fadump
> >   - fadump needs crashkernel parsing, vmcoreinfo exporting, and accessing
> > global variable 'elfcorehdr_addr';
> >   - kcore only needs vmcoreinfo exporting;
> >   - kdump needs all of the current kernel/crash_core.c.
> > 
> > So only enabling PROC_CORE or FA_DUMP will enable CRASH_CORE, this
> > mislead people that we enable crash dumping, actual it's not.
> > 
> > Secondly,
> > ---
> > It's not reasonable to allow KEXEC_CORE select CRASH_CORE.
> > 
> > Because KEXEC_CORE enables codes which allocate control pages, copy
> > kexec/kdump segments, and prepare for switching. These codes are
> > shared by both kexec reboot and kdump. We could want kexec reboot,
> > but disable kdump. In that case, CRASH_CORE should not be selected.
> > 
> >   
> >   CONFIG_CRASH_CORE=y
> >   CONFIG_KEXEC_CORE=y
> >   CONFIG_KEXEC=y
> >   CONFIG_KEXEC_FILE=y
> >  -
> > 
> > Thirdly,
> > ---
> > It's not reasonable to allow CRASH_DUMP select KEXEC_CORE.
> > 
> > That could make KEXEC_CORE, CRASH_DUMP are enabled independently from
> > KEXEC or KEXEC_FILE. However, w/o KEXEC or KEXEC_FILE, the KEXEC_CORE
> > code built in doesn't make any sense because no kernel loading or
> > switching will happen to utilize the KEXEC_CORE code.
> >   -
> >   CONFIG_CRASH_CORE=y
> >   CONFIG_KEXEC_CORE=y
> >   CONFIG_CRASH_DUMP=y
> >   -
> > 
> > In this case, what is worse, on arch sh and arm, KEXEC relies on MMU,
> > while CRASH_DUMP can still be enabled when !MMU, then compiling error is
> > seen as the lkp test robot reported in above link.
> > 
> >   --arch/sh/Kconfig--
> >   config ARCH_SUPPORTS_KEXEC
> >   def_bool MMU
> > 
> >   config ARCH_SUPPORTS_CRASH_DUMP
> >   def_bool BROKEN_ON_SMP
> >   ---
> > 
> > Changes:
> > ===
> > 1, split out crash_reserve.c from crash_core.c;
> > 2, split out vmcore_infoc. from crash_core.c;
> > 3, move crash related codes in kexec_core.c into crash_core.c;
> > 4, remove dependency of FA_DUMP on CRASH_DUMP;
> > 5, clean up kdump related config items;
> > 6, wrap up crash codes in crash related ifdefs on all 9 arch-es
> > which support crash dumping;
> > 
> > Achievement:
> > ===
> > With above changes, I can rearrange the config item logic as below (the 
> > right
> > item depends on or is selected by the left item):
> > 
> >  PROC_KCORE ---> VMCORE_INFO
> > 
> > |--> VMCORE_INFO
> >  FA_DUMP|
> > |--> CRASH_RESERVE
> 
> FA_DUMP also needs PROC_VMCORE (CRASH_DUMP by dependency, I guess).
> So, the FA_DUMP related changes here will need a relook..

Thanks for checking this.

So FA_DUMP needs vmcoreinfo exporting, crashkernel reservation,
/proc/vmcore. Then it's easy to adjust the kernel config item of FA_DUMP
to make it select CRASH_DUMP. Except of this, do you have concern about
the current code and Kconfig refactorying?


   >VMCORE_INFO
 /|
FA_DUMP--> CRASH_DUMP-->/-|>CRASH_RESERVE
\ |
  \>PROC_VMCORE


> 
> 
> >  >VMCORE_INFO
> > /
> > |>CRASH_RESERVE
> >  KEXEC  --|/|
> >   |--> KEXEC_CORE--> CRASH_DUMP-->/-|>PROC_VMCORE
> >  KEXEC_FILE --|   \ |
> > \>CRASH_HOTPLUG
> > 
> > 
> >  KEXEC  --|
> >   |--> KEXEC_CORE (for kexec reboot only)
> >  KEXEC_FILE --|
> > 
> > Test
> > 
> > On all 8 architectures, including x86_64, arm64, s390x, sh, arm, mips,
> > riscv, loongarch, I did below three cases of config item setting and
> > building all passed. Let me take configs on x86_64 as exampmle here:
> > 
> > (1) Both CONFIG_KEXEC and KEXEC_FILE is unset, then all kexec/kdump
> > items are unset automatically:
> > # Kexec and crash features
> > # CONFIG_KEXEC is not set
> > # CONFIG_KEXEC_FILE is not set