Re: [PATCH v2 0/7] kexec_file, x86, powerpc: refactoring for other architecutres

[Dave Young]

On 03/09/18 at 03:46pm, Dave Young wrote:
> Hi AKASHI,
> 
> On 03/09/18 at 04:18pm, AKASHI Takahiro wrote:
> > Dave,
> > 
> > On Fri, Mar 09, 2018 at 02:44:12PM +0800, Dave Young wrote:
> > > On 03/09/18 at 02:02pm, Dave Young wrote:
> > > > On 03/08/18 at 09:05am, Dave Young wrote:
> > > > > [Cc Andrew]
> > > > > 
> > > > > On 03/06/18 at 07:22pm, AKASHI Takahiro wrote:
> > > > > > This is a preparatory patch set for adding kexec_file support on 
> > > > > > arm64.
> > > > > > 
> > > > > > It was originally included in a arm64 patch set[1], but Philipp is 
> > > > > > also
> > > > > > working on their kexec_file support on s390[2] and some changes are 
> > > > > > now
> > > > > > conflicting.
> > > > > > 
> > > > > > So these common parts were extracted and put into a separate patch 
> > > > > > set for
> > > > > > better integration. What's more, my original patch#4 was split into 
> > > > > > a few
> > > > > > small chunks for easier review after Dave's comment.
> > > > > > 
> > > > > > As such, the resulting code is basically identical with my 
> > > > > > original, and
> > > > > > the only *visible* differences are:
> > > > > >   * renamings of _kexec_kernel_image_probe() and
> > > > > > _kimage_file_post_load_cleanup()
> > > > > >   * change one of types of arguments at prepare_elf64_headers()
> > > > > > Those, unfortunately, require a couple of trivial changes on the 
> > > > > > rest
> > > > > > (#1, #6 to #13) of my arm64 kexec_file patch set[1].
> > > > > > 
> > > > > > Patch#1 allows making a use of purgatory optional, particularly 
> > > > > > useful
> > > > > > for arm64.
> > > > > > Patch#2 commonalizes arch_kexec_kernel_{image_probe, image_load,
> > > > > > verify_sig}() and arch_kimage_file_post_load_cleanup() across 
> > > > > > architectures.
> > > > > > Patch#3-#7 is also intended to generalize parse_elf64_headers(), 
> > > > > > along with
> > > > > > exclude_mem_range(), to be made best re-use of.
> > > > > > 
> > > > > > [1] 
> > > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2018-February/561182.html
> > > > > > [2] http://lkml.iu.edu//hypermail/linux/kernel/1802.1/02596.html
> > > > > > 
> > > > > > 
> > > > > > Changes in v2 (Mar 6, 2018)
> > > > > > * use IS_ENABLED() instead of #ifdef's in 
> > > > > > kexec_calculate_store_digests() 
> > > > > > * rename _kexec_kernel_*() and make them static for now except for
> > > > > >   kexec_image_probe_default() which is actually used by 
> > > > > > arch(powerpc) code
> > > > > >   (Note: kexec_image_post_load_cleanup_default() will also be 
> > > > > > exported by
> > > > > >   arm64 patches.)
> > > > > > * change a type of kernel_map in prepare_elf64_headers() to "int"
> > > > > > * check for a total number of system ram regions in 
> > > > > > full_up_crash_elf_data()
> > > > > >   and use vzalloc() instead of vmalloc()
> > > > > > 
> > > > > > AKASHI Takahiro (7):
> > > > > >   kexec_file: make an use of purgatory optional
> > > > > >   kexec_file,x86,powerpc: factor out kexec_file_ops functions
> > > > > >   x86: kexec_file: purge system-ram walking from 
> > > > > > prepare_elf64_headers()
> > > > > >   x86: kexec_file: remove X86_64 dependency from 
> > > > > > prepare_elf64_headers()
> > > > > >   x86: kexec_file: lift CRASH_MAX_RANGES limit on crash_mem buffer
> > > > > >   x86: kexec_file: clean up prepare_elf64_headers()
> > > > > >   kexec_file, x86: move re-factored code to generic side
> > > > > > 
> > > > > >  arch/powerpc/Kconfig|   3 +
> > > > > >  arch/powerpc/include/asm/kexec.h|   2 +-
> > > > > >  arch/powerpc/kernel/kexec_elf_64.c  |   2 +-
> > > > > >  arch/powerpc/kernel/machine_kexec_file_64.c |  39 +---
> > > > > >  arch/x86/Kconfig|   3 +
> > > > > >  arch/x86/include/asm/kexec-bzimage64.h  |   2 +-
> > > > > >  arch/x86/kernel/crash.c | 334 
> > > > > > ++--
> > > > > >  arch/x86/kernel/kexec-bzimage64.c   |   2 +-
> > > > > >  arch/x86/kernel/machine_kexec_64.c  |  45 +---
> > > > > >  include/linux/kexec.h   |  32 ++-
> > > > > >  kernel/kexec_file.c | 240 
> > > > > > +++-
> > > > > >  11 files changed, 338 insertions(+), 366 deletions(-)
> > > > > > 
> > > > > > -- 
> > > > > > 2.16.2
> > > > > > 
> > > > > 
> > > > > AKASHI, thanks for another update, looks good to me:
> > > > > 
> > > > > Acked-by: Dave Young 
> > > > 
> > > > Hold on the ack, during today's tests kexec kernel can not boot, it
> > > > hangs early.  Will see if it is caused by this series and come back
> > > > later.
> > > 
> > > AKASHI, it seems the first patch causes the hang, can you take a look?
> > 
> > Sure, but can you first tell me specifics about what you have observed?
> 
> It is a kexec load test like below:
> kexec -s -l /boot/vmlinuz-`uname -r` --reuse-cmdline
> sync
> sync
> kexec -e
> 
> And 

Re: [PATCH 07/11] kexec_file: Simplify kexec_purgatory_setup_sechdrs 1

[kbuild test robot]

Hi Philipp,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc3 next-20180228]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Philipp-Rudo/kexec_file-Clean-up-purgatory-load/20180228-223538
config: x86_64-randconfig-s4-03010216 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: the 
linux-review/Philipp-Rudo/kexec_file-Clean-up-purgatory-load/20180228-223538 
HEAD 28c77b126e4b2796074bd704e2370a38beb037c1 builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   kernel/kexec_file.c: In function 'kexec_purgatory_setup_sechdrs':
>> kernel/kexec_file.c:798:3: error: expected ';' before '}' token
  }
  ^

vim +798 kernel/kexec_file.c

   713  
   714  /*
   715   * kexec_purgatory_setup_sechdrs - prepares the pi->sechdrs buffer.
   716   * @pi: Purgatory to be loaded.
   717   * @kbuf:   Buffer prepared to store purgatory.
   718   *
   719   * Allocates the memory needed for the buffer. Caller is responsible to 
free
   720   * the memory after use.
   721   *
   722   * Return: 0 on success, negative errno on error.
   723   */
   724  static int kexec_purgatory_setup_sechdrs(struct purgatory_info *pi,
   725   struct kexec_buf *kbuf)
   726  {
   727  unsigned long curr_load_addr;
   728  unsigned long load_addr;
   729  unsigned long bss_addr;
   730  unsigned long offset;
   731  unsigned char *buf_addr;
   732  unsigned char *src;
   733  Elf_Shdr *sechdrs;
   734  int i;
   735  
   736  sechdrs = vzalloc(pi->ehdr->e_shnum * sizeof(Elf_Shdr));
   737  if (!sechdrs)
   738  return -ENOMEM;
   739  memcpy(sechdrs, (void *)pi->ehdr + pi->ehdr->e_shoff,
   740 pi->ehdr->e_shnum * sizeof(Elf_Shdr));
   741  pi->sechdrs = sechdrs;
   742  
   743  /*
   744   * We seem to have multiple copies of sections. First copy is 
which
   745   * is embedded in kernel in read only section. Some of these 
sections
   746   * will be copied to a temporary buffer and relocated. And these
   747   * sections will finally be copied to their final destination at
   748   * segment load time.
   749   *
   750   * Use ->sh_offset to reflect section address in memory. It will
   751   * point to original read only copy if section is not 
allocatable.
   752   * Otherwise it will point to temporary copy which will be 
relocated.
   753   *
   754   * Use ->sh_addr to contain final address of the section where 
it
   755   * will go during execution time.
   756   */
   757  for (i = 0; i < pi->ehdr->e_shnum; i++) {
   758  if (sechdrs[i].sh_type == SHT_NOBITS)
   759  continue;
   760  
   761  sechdrs[i].sh_offset = (unsigned long)pi->ehdr +
   762  sechdrs[i].sh_offset;
   763  }
   764  
   765  /* Load SHF_ALLOC sections */
   766  buf_addr = kbuf->buffer;
   767  load_addr = curr_load_addr = kbuf->mem;
   768  bss_addr = load_addr + kbuf->bufsz;
   769  kbuf->image->start = pi->ehdr->e_entry;
   770  
   771  for (i = 0; i < pi->ehdr->e_shnum; i++) {
   772  unsigned long align;
   773  
   774  if (!(sechdrs[i].sh_flags & SHF_ALLOC))
   775  continue;
   776  
   777  align = sechdrs[i].sh_addralign;
   778  
   779  if (sechdrs[i].sh_type == SHT_NOBITS) {
   780  bss_addr = ALIGN(bss_addr, align);
   781  sechdrs[i].sh_addr = bss_addr;
   782  bss_addr += sechdrs[i].sh_size;
   783  continue;
   784  }
   785  
   786  curr_load_addr = ALIGN(curr_load_addr, align);
   787  offset = curr_load_addr - load_addr;
   788  /* We already modifed ->sh_offset to keep src addr */
   789  src = (char *)sechdrs[i].sh_offset;
   790  memcpy(buf_addr + offset, src, sechdrs[i].sh_size);
   791  
   792  if (sechdrs[i].sh_flags & SHF_EXECINSTR &&
   793  pi->ehdr->e_entry >= sechdrs[i].sh_addr &&
   794  pi->ehdr->e_entry < (sechdrs[i].sh_addr
   795   + sechdrs[i].sh_size)) {
   796  kbuf->image->start -= sechdrs[i].sh_addr;
   797  

Re: [PATCH v2 0/7] kexec_file, x86, powerpc: refactoring for other architecutres

[Dave Young]

Hi AKASHI,

On 03/09/18 at 04:18pm, AKASHI Takahiro wrote:
> Dave,
> 
> On Fri, Mar 09, 2018 at 02:44:12PM +0800, Dave Young wrote:
> > On 03/09/18 at 02:02pm, Dave Young wrote:
> > > On 03/08/18 at 09:05am, Dave Young wrote:
> > > > [Cc Andrew]
> > > > 
> > > > On 03/06/18 at 07:22pm, AKASHI Takahiro wrote:
> > > > > This is a preparatory patch set for adding kexec_file support on 
> > > > > arm64.
> > > > > 
> > > > > It was originally included in a arm64 patch set[1], but Philipp is 
> > > > > also
> > > > > working on their kexec_file support on s390[2] and some changes are 
> > > > > now
> > > > > conflicting.
> > > > > 
> > > > > So these common parts were extracted and put into a separate patch 
> > > > > set for
> > > > > better integration. What's more, my original patch#4 was split into a 
> > > > > few
> > > > > small chunks for easier review after Dave's comment.
> > > > > 
> > > > > As such, the resulting code is basically identical with my original, 
> > > > > and
> > > > > the only *visible* differences are:
> > > > >   * renamings of _kexec_kernel_image_probe() and
> > > > > _kimage_file_post_load_cleanup()
> > > > >   * change one of types of arguments at prepare_elf64_headers()
> > > > > Those, unfortunately, require a couple of trivial changes on the rest
> > > > > (#1, #6 to #13) of my arm64 kexec_file patch set[1].
> > > > > 
> > > > > Patch#1 allows making a use of purgatory optional, particularly useful
> > > > > for arm64.
> > > > > Patch#2 commonalizes arch_kexec_kernel_{image_probe, image_load,
> > > > > verify_sig}() and arch_kimage_file_post_load_cleanup() across 
> > > > > architectures.
> > > > > Patch#3-#7 is also intended to generalize parse_elf64_headers(), 
> > > > > along with
> > > > > exclude_mem_range(), to be made best re-use of.
> > > > > 
> > > > > [1] 
> > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2018-February/561182.html
> > > > > [2] http://lkml.iu.edu//hypermail/linux/kernel/1802.1/02596.html
> > > > > 
> > > > > 
> > > > > Changes in v2 (Mar 6, 2018)
> > > > > * use IS_ENABLED() instead of #ifdef's in 
> > > > > kexec_calculate_store_digests() 
> > > > > * rename _kexec_kernel_*() and make them static for now except for
> > > > >   kexec_image_probe_default() which is actually used by arch(powerpc) 
> > > > > code
> > > > >   (Note: kexec_image_post_load_cleanup_default() will also be 
> > > > > exported by
> > > > >   arm64 patches.)
> > > > > * change a type of kernel_map in prepare_elf64_headers() to "int"
> > > > > * check for a total number of system ram regions in 
> > > > > full_up_crash_elf_data()
> > > > >   and use vzalloc() instead of vmalloc()
> > > > > 
> > > > > AKASHI Takahiro (7):
> > > > >   kexec_file: make an use of purgatory optional
> > > > >   kexec_file,x86,powerpc: factor out kexec_file_ops functions
> > > > >   x86: kexec_file: purge system-ram walking from 
> > > > > prepare_elf64_headers()
> > > > >   x86: kexec_file: remove X86_64 dependency from 
> > > > > prepare_elf64_headers()
> > > > >   x86: kexec_file: lift CRASH_MAX_RANGES limit on crash_mem buffer
> > > > >   x86: kexec_file: clean up prepare_elf64_headers()
> > > > >   kexec_file, x86: move re-factored code to generic side
> > > > > 
> > > > >  arch/powerpc/Kconfig|   3 +
> > > > >  arch/powerpc/include/asm/kexec.h|   2 +-
> > > > >  arch/powerpc/kernel/kexec_elf_64.c  |   2 +-
> > > > >  arch/powerpc/kernel/machine_kexec_file_64.c |  39 +---
> > > > >  arch/x86/Kconfig|   3 +
> > > > >  arch/x86/include/asm/kexec-bzimage64.h  |   2 +-
> > > > >  arch/x86/kernel/crash.c | 334 
> > > > > ++--
> > > > >  arch/x86/kernel/kexec-bzimage64.c   |   2 +-
> > > > >  arch/x86/kernel/machine_kexec_64.c  |  45 +---
> > > > >  include/linux/kexec.h   |  32 ++-
> > > > >  kernel/kexec_file.c | 240 
> > > > > +++-
> > > > >  11 files changed, 338 insertions(+), 366 deletions(-)
> > > > > 
> > > > > -- 
> > > > > 2.16.2
> > > > > 
> > > > 
> > > > AKASHI, thanks for another update, looks good to me:
> > > > 
> > > > Acked-by: Dave Young 
> > > 
> > > Hold on the ack, during today's tests kexec kernel can not boot, it
> > > hangs early.  Will see if it is caused by this series and come back
> > > later.
> > 
> > AKASHI, it seems the first patch causes the hang, can you take a look?
> 
> Sure, but can you first tell me specifics about what you have observed?

It is a kexec load test like below:
kexec -s -l /boot/vmlinuz-`uname -r` --reuse-cmdline
sync
sync
kexec -e

And it hangs after the message "Starting new kernel".   Now I'm not sure
how I tested the vmcore parsing before, maybe I forgot to add "-s"
option in kexec-tools..

Thanks
Dave

> 
> Thanks,
> -Takahiro AKASHI
> 
> 
> > > 
> > > > 
> > > > Thanks
> > > > Dave
> > > 
> > > Thanks
> > > Dave

Re: [PATCH v2 0/7] kexec_file, x86, powerpc: refactoring for other architecutres

[AKASHI Takahiro]

Dave,

On Fri, Mar 09, 2018 at 02:44:12PM +0800, Dave Young wrote:
> On 03/09/18 at 02:02pm, Dave Young wrote:
> > On 03/08/18 at 09:05am, Dave Young wrote:
> > > [Cc Andrew]
> > > 
> > > On 03/06/18 at 07:22pm, AKASHI Takahiro wrote:
> > > > This is a preparatory patch set for adding kexec_file support on arm64.
> > > > 
> > > > It was originally included in a arm64 patch set[1], but Philipp is also
> > > > working on their kexec_file support on s390[2] and some changes are now
> > > > conflicting.
> > > > 
> > > > So these common parts were extracted and put into a separate patch set 
> > > > for
> > > > better integration. What's more, my original patch#4 was split into a 
> > > > few
> > > > small chunks for easier review after Dave's comment.
> > > > 
> > > > As such, the resulting code is basically identical with my original, and
> > > > the only *visible* differences are:
> > > >   * renamings of _kexec_kernel_image_probe() and
> > > > _kimage_file_post_load_cleanup()
> > > >   * change one of types of arguments at prepare_elf64_headers()
> > > > Those, unfortunately, require a couple of trivial changes on the rest
> > > > (#1, #6 to #13) of my arm64 kexec_file patch set[1].
> > > > 
> > > > Patch#1 allows making a use of purgatory optional, particularly useful
> > > > for arm64.
> > > > Patch#2 commonalizes arch_kexec_kernel_{image_probe, image_load,
> > > > verify_sig}() and arch_kimage_file_post_load_cleanup() across 
> > > > architectures.
> > > > Patch#3-#7 is also intended to generalize parse_elf64_headers(), along 
> > > > with
> > > > exclude_mem_range(), to be made best re-use of.
> > > > 
> > > > [1] 
> > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2018-February/561182.html
> > > > [2] http://lkml.iu.edu//hypermail/linux/kernel/1802.1/02596.html
> > > > 
> > > > 
> > > > Changes in v2 (Mar 6, 2018)
> > > > * use IS_ENABLED() instead of #ifdef's in 
> > > > kexec_calculate_store_digests() 
> > > > * rename _kexec_kernel_*() and make them static for now except for
> > > >   kexec_image_probe_default() which is actually used by arch(powerpc) 
> > > > code
> > > >   (Note: kexec_image_post_load_cleanup_default() will also be exported 
> > > > by
> > > >   arm64 patches.)
> > > > * change a type of kernel_map in prepare_elf64_headers() to "int"
> > > > * check for a total number of system ram regions in 
> > > > full_up_crash_elf_data()
> > > >   and use vzalloc() instead of vmalloc()
> > > > 
> > > > AKASHI Takahiro (7):
> > > >   kexec_file: make an use of purgatory optional
> > > >   kexec_file,x86,powerpc: factor out kexec_file_ops functions
> > > >   x86: kexec_file: purge system-ram walking from prepare_elf64_headers()
> > > >   x86: kexec_file: remove X86_64 dependency from prepare_elf64_headers()
> > > >   x86: kexec_file: lift CRASH_MAX_RANGES limit on crash_mem buffer
> > > >   x86: kexec_file: clean up prepare_elf64_headers()
> > > >   kexec_file, x86: move re-factored code to generic side
> > > > 
> > > >  arch/powerpc/Kconfig|   3 +
> > > >  arch/powerpc/include/asm/kexec.h|   2 +-
> > > >  arch/powerpc/kernel/kexec_elf_64.c  |   2 +-
> > > >  arch/powerpc/kernel/machine_kexec_file_64.c |  39 +---
> > > >  arch/x86/Kconfig|   3 +
> > > >  arch/x86/include/asm/kexec-bzimage64.h  |   2 +-
> > > >  arch/x86/kernel/crash.c | 334 
> > > > ++--
> > > >  arch/x86/kernel/kexec-bzimage64.c   |   2 +-
> > > >  arch/x86/kernel/machine_kexec_64.c  |  45 +---
> > > >  include/linux/kexec.h   |  32 ++-
> > > >  kernel/kexec_file.c | 240 +++-
> > > >  11 files changed, 338 insertions(+), 366 deletions(-)
> > > > 
> > > > -- 
> > > > 2.16.2
> > > > 
> > > 
> > > AKASHI, thanks for another update, looks good to me:
> > > 
> > > Acked-by: Dave Young 
> > 
> > Hold on the ack, during today's tests kexec kernel can not boot, it
> > hangs early.  Will see if it is caused by this series and come back
> > later.
> 
> AKASHI, it seems the first patch causes the hang, can you take a look?

Sure, but can you first tell me specifics about what you have observed?

Thanks,
-Takahiro AKASHI


> > 
> > > 
> > > Thanks
> > > Dave
> > 
> > Thanks
> > Dave

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

Re: [PATCH v2 0/7] kexec_file, x86, powerpc: refactoring for other architecutres

[Dave Young]

On 03/09/18 at 02:02pm, Dave Young wrote:
> On 03/08/18 at 09:05am, Dave Young wrote:
> > [Cc Andrew]
> > 
> > On 03/06/18 at 07:22pm, AKASHI Takahiro wrote:
> > > This is a preparatory patch set for adding kexec_file support on arm64.
> > > 
> > > It was originally included in a arm64 patch set[1], but Philipp is also
> > > working on their kexec_file support on s390[2] and some changes are now
> > > conflicting.
> > > 
> > > So these common parts were extracted and put into a separate patch set for
> > > better integration. What's more, my original patch#4 was split into a few
> > > small chunks for easier review after Dave's comment.
> > > 
> > > As such, the resulting code is basically identical with my original, and
> > > the only *visible* differences are:
> > >   * renamings of _kexec_kernel_image_probe() and
> > > _kimage_file_post_load_cleanup()
> > >   * change one of types of arguments at prepare_elf64_headers()
> > > Those, unfortunately, require a couple of trivial changes on the rest
> > > (#1, #6 to #13) of my arm64 kexec_file patch set[1].
> > > 
> > > Patch#1 allows making a use of purgatory optional, particularly useful
> > > for arm64.
> > > Patch#2 commonalizes arch_kexec_kernel_{image_probe, image_load,
> > > verify_sig}() and arch_kimage_file_post_load_cleanup() across 
> > > architectures.
> > > Patch#3-#7 is also intended to generalize parse_elf64_headers(), along 
> > > with
> > > exclude_mem_range(), to be made best re-use of.
> > > 
> > > [1] 
> > > http://lists.infradead.org/pipermail/linux-arm-kernel/2018-February/561182.html
> > > [2] http://lkml.iu.edu//hypermail/linux/kernel/1802.1/02596.html
> > > 
> > > 
> > > Changes in v2 (Mar 6, 2018)
> > > * use IS_ENABLED() instead of #ifdef's in kexec_calculate_store_digests() 
> > > * rename _kexec_kernel_*() and make them static for now except for
> > >   kexec_image_probe_default() which is actually used by arch(powerpc) code
> > >   (Note: kexec_image_post_load_cleanup_default() will also be exported by
> > >   arm64 patches.)
> > > * change a type of kernel_map in prepare_elf64_headers() to "int"
> > > * check for a total number of system ram regions in 
> > > full_up_crash_elf_data()
> > >   and use vzalloc() instead of vmalloc()
> > > 
> > > AKASHI Takahiro (7):
> > >   kexec_file: make an use of purgatory optional
> > >   kexec_file,x86,powerpc: factor out kexec_file_ops functions
> > >   x86: kexec_file: purge system-ram walking from prepare_elf64_headers()
> > >   x86: kexec_file: remove X86_64 dependency from prepare_elf64_headers()
> > >   x86: kexec_file: lift CRASH_MAX_RANGES limit on crash_mem buffer
> > >   x86: kexec_file: clean up prepare_elf64_headers()
> > >   kexec_file, x86: move re-factored code to generic side
> > > 
> > >  arch/powerpc/Kconfig|   3 +
> > >  arch/powerpc/include/asm/kexec.h|   2 +-
> > >  arch/powerpc/kernel/kexec_elf_64.c  |   2 +-
> > >  arch/powerpc/kernel/machine_kexec_file_64.c |  39 +---
> > >  arch/x86/Kconfig|   3 +
> > >  arch/x86/include/asm/kexec-bzimage64.h  |   2 +-
> > >  arch/x86/kernel/crash.c | 334 
> > > ++--
> > >  arch/x86/kernel/kexec-bzimage64.c   |   2 +-
> > >  arch/x86/kernel/machine_kexec_64.c  |  45 +---
> > >  include/linux/kexec.h   |  32 ++-
> > >  kernel/kexec_file.c | 240 +++-
> > >  11 files changed, 338 insertions(+), 366 deletions(-)
> > > 
> > > -- 
> > > 2.16.2
> > > 
> > 
> > AKASHI, thanks for another update, looks good to me:
> > 
> > Acked-by: Dave Young 
> 
> Hold on the ack, during today's tests kexec kernel can not boot, it
> hangs early.  Will see if it is caused by this series and come back
> later.

AKASHI, it seems the first patch causes the hang, can you take a look?

> 
> > 
> > Thanks
> > Dave
> 
> Thanks
> Dave

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

Re: [PATCH v2 0/7] kexec_file, x86, powerpc: refactoring for other architecutres

[Dave Young]

On 03/08/18 at 09:05am, Dave Young wrote:
> [Cc Andrew]
> 
> On 03/06/18 at 07:22pm, AKASHI Takahiro wrote:
> > This is a preparatory patch set for adding kexec_file support on arm64.
> > 
> > It was originally included in a arm64 patch set[1], but Philipp is also
> > working on their kexec_file support on s390[2] and some changes are now
> > conflicting.
> > 
> > So these common parts were extracted and put into a separate patch set for
> > better integration. What's more, my original patch#4 was split into a few
> > small chunks for easier review after Dave's comment.
> > 
> > As such, the resulting code is basically identical with my original, and
> > the only *visible* differences are:
> >   * renamings of _kexec_kernel_image_probe() and
> > _kimage_file_post_load_cleanup()
> >   * change one of types of arguments at prepare_elf64_headers()
> > Those, unfortunately, require a couple of trivial changes on the rest
> > (#1, #6 to #13) of my arm64 kexec_file patch set[1].
> > 
> > Patch#1 allows making a use of purgatory optional, particularly useful
> > for arm64.
> > Patch#2 commonalizes arch_kexec_kernel_{image_probe, image_load,
> > verify_sig}() and arch_kimage_file_post_load_cleanup() across architectures.
> > Patch#3-#7 is also intended to generalize parse_elf64_headers(), along with
> > exclude_mem_range(), to be made best re-use of.
> > 
> > [1] 
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2018-February/561182.html
> > [2] http://lkml.iu.edu//hypermail/linux/kernel/1802.1/02596.html
> > 
> > 
> > Changes in v2 (Mar 6, 2018)
> > * use IS_ENABLED() instead of #ifdef's in kexec_calculate_store_digests() 
> > * rename _kexec_kernel_*() and make them static for now except for
> >   kexec_image_probe_default() which is actually used by arch(powerpc) code
> >   (Note: kexec_image_post_load_cleanup_default() will also be exported by
> >   arm64 patches.)
> > * change a type of kernel_map in prepare_elf64_headers() to "int"
> > * check for a total number of system ram regions in full_up_crash_elf_data()
> >   and use vzalloc() instead of vmalloc()
> > 
> > AKASHI Takahiro (7):
> >   kexec_file: make an use of purgatory optional
> >   kexec_file,x86,powerpc: factor out kexec_file_ops functions
> >   x86: kexec_file: purge system-ram walking from prepare_elf64_headers()
> >   x86: kexec_file: remove X86_64 dependency from prepare_elf64_headers()
> >   x86: kexec_file: lift CRASH_MAX_RANGES limit on crash_mem buffer
> >   x86: kexec_file: clean up prepare_elf64_headers()
> >   kexec_file, x86: move re-factored code to generic side
> > 
> >  arch/powerpc/Kconfig|   3 +
> >  arch/powerpc/include/asm/kexec.h|   2 +-
> >  arch/powerpc/kernel/kexec_elf_64.c  |   2 +-
> >  arch/powerpc/kernel/machine_kexec_file_64.c |  39 +---
> >  arch/x86/Kconfig|   3 +
> >  arch/x86/include/asm/kexec-bzimage64.h  |   2 +-
> >  arch/x86/kernel/crash.c | 334 
> > ++--
> >  arch/x86/kernel/kexec-bzimage64.c   |   2 +-
> >  arch/x86/kernel/machine_kexec_64.c  |  45 +---
> >  include/linux/kexec.h   |  32 ++-
> >  kernel/kexec_file.c | 240 +++-
> >  11 files changed, 338 insertions(+), 366 deletions(-)
> > 
> > -- 
> > 2.16.2
> > 
> 
> AKASHI, thanks for another update, looks good to me:
> 
> Acked-by: Dave Young 

Hold on the ack, during today's tests kexec kernel can not boot, it
hangs early.  Will see if it is caused by this series and come back
later.

> 
> Thanks
> Dave

Thanks
Dave

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

RE: [PATCH] makedumpfile: fix for hugepages filtering

[Masaki Tachibana]

Hi Hari,

Thank you for your patch.
It looks good.
I will merge it into V1.6.4.

Thanks
Tachibana

P.S. Sorry. I am prohibited from sending a mail to free mail address such as 
gmail.com.


> -Original Message-
> From: kexec [mailto:kexec-boun...@lists.infradead.org] On Behalf Of Hari 
> Bathini
> Sent: Friday, March 09, 2018 3:10 AM
> To: Atsushi Kumagai 
> Cc: Dave Young ; ptesa...@suse.cz; Kexec-ml 
> ; pi...@redhat.com;
> andrej.skvort...@gmail.com
> Subject: [PATCH] makedumpfile: fix for hugepages filtering
> 
> Kernel commit 036e7aa49fb2 changed 'compound_dtor' & 'compound_order'
> types from 'unsigned short' to 'unsigned char'. Fix it here to ensure
> hugepages are filtered properly.
> 
> Also, makedumpfile tool commit 484c6b18624 used 'int' type for 'dtor'
> argument in 'isHugetlb' function. While this works in recent kernels
> that use 'unsigned short/char' type for 'compound_dtor', it breaks
> older kernels that used address of 'free_huge_page' as dtor. Fix it
> by changing 'dtor' type.
> 
> Signed-off-by: Hari Bathini 
> ---
>  makedumpfile.c |   30 --
>  makedumpfile.h |1 +
>  2 files changed, 25 insertions(+), 6 deletions(-)
> 
> diff --git a/makedumpfile.c b/makedumpfile.c
> index ed138d3..ac8483d 100644
> --- a/makedumpfile.c
> +++ b/makedumpfile.c
> @@ -241,7 +241,7 @@ is_in_same_page(unsigned long vaddr1, unsigned long 
> vaddr2)
>  }
> 
>  static inline int
> -isHugetlb(int dtor)
> +isHugetlb(unsigned long dtor)
>  {
>  return ((NUMBER(HUGETLB_PAGE_DTOR) != NOT_FOUND_NUMBER)
>   && (NUMBER(HUGETLB_PAGE_DTOR) == dtor))
> @@ -5798,18 +5798,36 @@ __exclude_unnecessary_pages(unsigned long mem_map,
>* and PGMM_CACHED is a power of 2.
>*/
>   if ((index_pg < PGMM_CACHED - 1) && isCompoundHead(flags)) {
> - if (order_offset)
> - compound_order = USHORT(pcache + SIZE(page) + 
> order_offset);
> + unsigned long long addr =
> + (unsigned long long)(pcache + SIZE(page));
> +
> + if (order_offset) {
> + if (info->kernel_version >=
> + KERNEL_VERSION(4, 16, 0)) {
> + compound_order =
> + UCHAR(addr + order_offset);
> + } else {
> + compound_order =
> + USHORT(addr + order_offset);
> + }
> + }
> 
>   if (dtor_offset) {
>   /*
>* compound_dtor has been changed from the 
> address of descriptor
>* to the ID of it since linux-4.4.
>*/
> - if (info->kernel_version >= KERNEL_VERSION(4, 
> 4, 0)) {
> - compound_dtor = USHORT(pcache + 
> SIZE(page) + dtor_offset);
> + if (info->kernel_version >=
> + KERNEL_VERSION(4, 16, 0)) {
> + compound_dtor =
> + UCHAR(addr + dtor_offset);
> + } else if (info->kernel_version >=
> +KERNEL_VERSION(4, 4, 0)) {
> + compound_dtor =
> + USHORT(addr + dtor_offset);
>   } else {
> - compound_dtor = ULONG(pcache + 
> SIZE(page) + dtor_offset);
> + compound_dtor =
> + ULONG(addr + dtor_offset);
>   }
>   }
> 
> diff --git a/makedumpfile.h b/makedumpfile.h
> index 01eece2..4cfad98 100644
> --- a/makedumpfile.h
> +++ b/makedumpfile.h
> @@ -241,6 +241,7 @@ static inline int string_exists(char *s) { return (s ? 
> TRUE : FALSE); }
>string_exists((char *)(B)) &&  \
>   (strncmp((char *)(A), (char *)(B), strlen((char *)(B))) == 0))
> 
> +#define UCHAR(ADDR)  *((unsigned char *)(ADDR))
>  #define USHORT(ADDR) *((unsigned short *)(ADDR))
>  #define UINT(ADDR)   *((unsigned int *)(ADDR))
>  #define ULONG(ADDR)  *((unsigned long *)(ADDR))
> 
> 
> ___
> 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 00/11] kexec_file: Clean up purgatory load

[Dave Young]

On 03/09/18 at 01:19pm, Dave Young wrote:
> Hi Philipp,
> On 02/26/18 at 04:16pm, Philipp Rudo wrote:
> > 
> > Hi everybody
> > 
> > following the discussion with Dave and AKASHI, here are the common code
> > patches extracted from my recent patch set (Add kexec_file_load support to
> > s390) [1]. The patches were extracted to allow upstream integration together
> > with AKASHI's common code patches before the arch code gets adjusted to the
> > new base.
> > 
> > The reason for this series is to prepare common code for adding
> > kexec_file_load to s390 as well as cleaning up the mis-use of the sh_offset
> > field during purgatory load. In detail this series contains:
> > 
> > Patch #1&2: Minor cleanups/fixes.
> > 
> > Patch #3-9: Clean up the purgatory load/relocation code. Especially remove
> > the mis-use of the purgatory_info->sechdrs->sh_offset field, currently
> > holding a pointer into either kexec_purgatory (ro) or purgatory_buf (rw)
> > depending on the section. With these patches the section address will be
> > calculated verbosely and sh_offset will contain the offset of the section
> > in the stripped purgatory binary (purgatory_buf).
> > 
> > Patch #10: Allows architectures to set the purgatory load address. This
> > patch is important for s390 as the kernel and purgatory have to be loaded
> > to fixed addresses. In current code this is impossible as the purgatory
> > load is opaque to the architecture.
> > 
> > Patch #11: Moves x86 purgatories sha implementation to common lib/
> > directory to allow reuse in other architectures.
> > 
> > The patches apply to v4.16-rc3. There are no changes compared to [1] (all
> > requested changes only affected s390 code). Please note that I had to touch
> > arch code for x86 and power a little. In theory this should not change the
> > behavior but I don't have a way to test it. Cross-compiling with
> > defconfig [2] works fine for both.
> > 
> > Thanks
> > Philipp
> > 
> > [1] http://lists.infradead.org/pipermail/kexec/2018-February/019926.html
> > [2] On x86 with the orc unwinder and stack validation turned off. objtool
> > SEGFAULTs on s390...
> > 
> > Philipp Rudo (11):
> >   kexec_file: Silence compile warnings
> >   kexec_file: Remove checks in kexec_purgatory_load
> >   kexec_file: Make purgatory_info->ehdr const
> >   kexec_file: Search symbols in read-only kexec_purgatory
> >   kexec_file: Use read-only sections in arch_kexec_apply_relocations*
> >   kexec_file: Split up __kexec_load_puragory
> >   kexec_file: Simplify kexec_purgatory_setup_sechdrs 1
> >   kexec_file: Simplify kexec_purgatory_setup_sechdrs 2
> >   kexec_file: Remove mis-use of sh_offset field
> >   kexec_file: Allow archs to set purgatory load address
> >   kexec_file: Move purgatories sha256 to common code
> > 
> >  arch/powerpc/kernel/kexec_elf_64.c |   9 +-
> >  arch/x86/kernel/kexec-bzimage64.c  |   8 +-
> >  arch/x86/kernel/machine_kexec_64.c |  66 ++---
> >  arch/x86/purgatory/Makefile|   3 +
> >  arch/x86/purgatory/purgatory.c |   2 +-
> >  include/linux/kexec.h  |  38 +--
> >  {arch/x86/purgatory => include/linux}/sha256.h |  10 +-
> >  kernel/kexec_file.c| 375 
> > -
> >  {arch/x86/purgatory => lib}/sha256.c   |   4 +-
> >  9 files changed, 244 insertions(+), 271 deletions(-)
> >  rename {arch/x86/purgatory => include/linux}/sha256.h (63%)
> >  rename {arch/x86/purgatory => lib}/sha256.c (99%)
> > 
> > -- 
> > 2.13.5
> > 
> 
> I did a test on x86, but it failed:
> [   15.636489] kexec: Undefined symbol: memcpy
> [   15.636496] kexec-bzImage64: Loading purgatory failed
> [   33.603356] kexec: Undefined symbol: memcpy
> [   33.603362] kexec-bzImage64: Loading purgatory failed
> 
> I think this relates to the sha256 splitting patch.
> 
> After reverting the sha256 patch (the last one), rebuilt a kernel but it still
> failed to load:
> 
> # kexec -d -s -l /home/dyoung/git/linux-x86/sign/bzImage.signed 
> Try gzip decompression.
> Try LZMA decompression.
> lzma_decompress_file: read on /home/dyoung/git/linux-x86/sign/bzImage.signed 
> of 65536 bytes failed

Oops, this lzma error message should be not harmful, actually kernel should
have been loaded, I will do more tests anyway.

> 
> Thanks
> Dave

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

[RESEND PATCH] makedumpfile: fix for hugepages filtering

[Hari Bathini]

Kernel commit 036e7aa49fb2 changed 'compound_dtor' & 'compound_order'
types from 'unsigned short' to 'unsigned char'. Fix it here to ensure
hugepages are filtered properly.

Also, makedumpfile tool commit 484c6b18624 used 'int' type for 'dtor'
argument in 'isHugetlb' function. While this works in recent kernels
that use 'unsigned short/char' type for 'compound_dtor', it breaks
older kernels that used address of 'free_huge_page' as dtor. Fix it
by changing 'dtor' type.

Signed-off-by: Hari Bathini 
---

* Resending the patch by marking to the current maintainers.

 makedumpfile.c |   30 --
 makedumpfile.h |1 +
 2 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/makedumpfile.c b/makedumpfile.c
index ed138d3..ac8483d 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -241,7 +241,7 @@ is_in_same_page(unsigned long vaddr1, unsigned long vaddr2)
 }
 
 static inline int
-isHugetlb(int dtor)
+isHugetlb(unsigned long dtor)
 {
 return ((NUMBER(HUGETLB_PAGE_DTOR) != NOT_FOUND_NUMBER)
&& (NUMBER(HUGETLB_PAGE_DTOR) == dtor))
@@ -5798,18 +5798,36 @@ __exclude_unnecessary_pages(unsigned long mem_map,
 * and PGMM_CACHED is a power of 2.
 */
if ((index_pg < PGMM_CACHED - 1) && isCompoundHead(flags)) {
-   if (order_offset)
-   compound_order = USHORT(pcache + SIZE(page) + 
order_offset);
+   unsigned long long addr =
+   (unsigned long long)(pcache + SIZE(page));
+
+   if (order_offset) {
+   if (info->kernel_version >=
+   KERNEL_VERSION(4, 16, 0)) {
+   compound_order =
+   UCHAR(addr + order_offset);
+   } else {
+   compound_order =
+   USHORT(addr + order_offset);
+   }
+   }
 
if (dtor_offset) {
/*
 * compound_dtor has been changed from the 
address of descriptor
 * to the ID of it since linux-4.4.
 */
-   if (info->kernel_version >= KERNEL_VERSION(4, 
4, 0)) {
-   compound_dtor = USHORT(pcache + 
SIZE(page) + dtor_offset);
+   if (info->kernel_version >=
+   KERNEL_VERSION(4, 16, 0)) {
+   compound_dtor =
+   UCHAR(addr + dtor_offset);
+   } else if (info->kernel_version >=
+  KERNEL_VERSION(4, 4, 0)) {
+   compound_dtor =
+   USHORT(addr + dtor_offset);
} else {
-   compound_dtor = ULONG(pcache + 
SIZE(page) + dtor_offset);
+   compound_dtor =
+   ULONG(addr + dtor_offset);
}
}
 
diff --git a/makedumpfile.h b/makedumpfile.h
index 01eece2..4cfad98 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -241,6 +241,7 @@ static inline int string_exists(char *s) { return (s ? TRUE 
: FALSE); }
 string_exists((char *)(B)) &&  \
(strncmp((char *)(A), (char *)(B), strlen((char *)(B))) == 0))
 
+#define UCHAR(ADDR)*((unsigned char *)(ADDR))
 #define USHORT(ADDR)   *((unsigned short *)(ADDR))
 #define UINT(ADDR) *((unsigned int *)(ADDR))
 #define ULONG(ADDR)*((unsigned long *)(ADDR))


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

Re: [PATCH 00/11] kexec_file: Clean up purgatory load

[Dave Young]

Hi Philipp,
On 02/26/18 at 04:16pm, Philipp Rudo wrote:
> 
> Hi everybody
> 
> following the discussion with Dave and AKASHI, here are the common code
> patches extracted from my recent patch set (Add kexec_file_load support to
> s390) [1]. The patches were extracted to allow upstream integration together
> with AKASHI's common code patches before the arch code gets adjusted to the
> new base.
> 
> The reason for this series is to prepare common code for adding
> kexec_file_load to s390 as well as cleaning up the mis-use of the sh_offset
> field during purgatory load. In detail this series contains:
> 
> Patch #1&2: Minor cleanups/fixes.
> 
> Patch #3-9: Clean up the purgatory load/relocation code. Especially remove
> the mis-use of the purgatory_info->sechdrs->sh_offset field, currently
> holding a pointer into either kexec_purgatory (ro) or purgatory_buf (rw)
> depending on the section. With these patches the section address will be
> calculated verbosely and sh_offset will contain the offset of the section
> in the stripped purgatory binary (purgatory_buf).
> 
> Patch #10: Allows architectures to set the purgatory load address. This
> patch is important for s390 as the kernel and purgatory have to be loaded
> to fixed addresses. In current code this is impossible as the purgatory
> load is opaque to the architecture.
> 
> Patch #11: Moves x86 purgatories sha implementation to common lib/
> directory to allow reuse in other architectures.
> 
> The patches apply to v4.16-rc3. There are no changes compared to [1] (all
> requested changes only affected s390 code). Please note that I had to touch
> arch code for x86 and power a little. In theory this should not change the
> behavior but I don't have a way to test it. Cross-compiling with
> defconfig [2] works fine for both.
> 
> Thanks
> Philipp
> 
> [1] http://lists.infradead.org/pipermail/kexec/2018-February/019926.html
> [2] On x86 with the orc unwinder and stack validation turned off. objtool
> SEGFAULTs on s390...
> 
> Philipp Rudo (11):
>   kexec_file: Silence compile warnings
>   kexec_file: Remove checks in kexec_purgatory_load
>   kexec_file: Make purgatory_info->ehdr const
>   kexec_file: Search symbols in read-only kexec_purgatory
>   kexec_file: Use read-only sections in arch_kexec_apply_relocations*
>   kexec_file: Split up __kexec_load_puragory
>   kexec_file: Simplify kexec_purgatory_setup_sechdrs 1
>   kexec_file: Simplify kexec_purgatory_setup_sechdrs 2
>   kexec_file: Remove mis-use of sh_offset field
>   kexec_file: Allow archs to set purgatory load address
>   kexec_file: Move purgatories sha256 to common code
> 
>  arch/powerpc/kernel/kexec_elf_64.c |   9 +-
>  arch/x86/kernel/kexec-bzimage64.c  |   8 +-
>  arch/x86/kernel/machine_kexec_64.c |  66 ++---
>  arch/x86/purgatory/Makefile|   3 +
>  arch/x86/purgatory/purgatory.c |   2 +-
>  include/linux/kexec.h  |  38 +--
>  {arch/x86/purgatory => include/linux}/sha256.h |  10 +-
>  kernel/kexec_file.c| 375 
> -
>  {arch/x86/purgatory => lib}/sha256.c   |   4 +-
>  9 files changed, 244 insertions(+), 271 deletions(-)
>  rename {arch/x86/purgatory => include/linux}/sha256.h (63%)
>  rename {arch/x86/purgatory => lib}/sha256.c (99%)
> 
> -- 
> 2.13.5
> 

I did a test on x86, but it failed:
[   15.636489] kexec: Undefined symbol: memcpy
[   15.636496] kexec-bzImage64: Loading purgatory failed
[   33.603356] kexec: Undefined symbol: memcpy
[   33.603362] kexec-bzImage64: Loading purgatory failed

I think this relates to the sha256 splitting patch.

After reverting the sha256 patch (the last one), rebuilt a kernel but it still
failed to load:

# kexec -d -s -l /home/dyoung/git/linux-x86/sign/bzImage.signed 
Try gzip decompression.
Try LZMA decompression.
lzma_decompress_file: read on /home/dyoung/git/linux-x86/sign/bzImage.signed of 
65536 bytes failed

Thanks
Dave

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

Re: [PATCH 08/11] kexec_file: Simplify kexec_purgatory_setup_sechdrs 2

[Dave Young]

Hi,

On 02/26/18 at 04:16pm, Philipp Rudo wrote:
> The main loop currently uses quite a lot of variables to update the section
> headers. Some of them are unnecessary. So clean them up a little.
> 

It looks better to use some patch subject eg below:
"Remove unnecessary variables in kexec_purgatory_setup_sechdrs"

> Signed-off-by: Philipp Rudo 
> ---
>  kernel/kexec_file.c | 34 --
>  1 file changed, 12 insertions(+), 22 deletions(-)
> 
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index bb31a3b627c2..746b91e46e34 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -724,12 +724,8 @@ static int kexec_purgatory_setup_kbuf(struct 
> purgatory_info *pi,
>  static int kexec_purgatory_setup_sechdrs(struct purgatory_info *pi,
>struct kexec_buf *kbuf)
>  {
> - unsigned long curr_load_addr;
> - unsigned long load_addr;
>   unsigned long bss_addr;
>   unsigned long offset;
> - unsigned char *buf_addr;
> - unsigned char *src;
>   Elf_Shdr *sechdrs;
>   int i;
>  
> @@ -762,20 +758,18 @@ static int kexec_purgatory_setup_sechdrs(struct 
> purgatory_info *pi,
>   sechdrs[i].sh_offset;
>   }
>  
> - /* Load SHF_ALLOC sections */
> - buf_addr = kbuf->buffer;
> - load_addr = curr_load_addr = kbuf->mem;
> - bss_addr = load_addr + kbuf->bufsz;
> + offset = 0;
> + bss_addr = kbuf->mem + kbuf->bufsz;
>   kbuf->image->start = pi->ehdr->e_entry;
>  
>   for (i = 0; i < pi->ehdr->e_shnum; i++) {
>   unsigned long align;
> + void *src, *dst;
>  
>   if (!(sechdrs[i].sh_flags & SHF_ALLOC))
>   continue;
>  
>   align = sechdrs[i].sh_addralign;
> -
>   if (sechdrs[i].sh_type == SHT_NOBITS) {
>   bss_addr = ALIGN(bss_addr, align);
>   sechdrs[i].sh_addr = bss_addr;
> @@ -783,31 +777,27 @@ static int kexec_purgatory_setup_sechdrs(struct 
> purgatory_info *pi,
>   continue;
>   }
>  
> - curr_load_addr = ALIGN(curr_load_addr, align);
> - offset = curr_load_addr - load_addr;
> - /* We already modifed ->sh_offset to keep src addr */
> - src = (char *)sechdrs[i].sh_offset;
> - memcpy(buf_addr + offset, src, sechdrs[i].sh_size);
> -
> + offset = ALIGN(offset, align);
>   if (sechdrs[i].sh_flags & SHF_EXECINSTR &&
>   pi->ehdr->e_entry >= sechdrs[i].sh_addr &&
>   pi->ehdr->e_entry < (sechdrs[i].sh_addr
>+ sechdrs[i].sh_size)) {
>   kbuf->image->start -= sechdrs[i].sh_addr;
> - kbuf->image->start += curr_load_addr
> + kbuf->image->start += kbuf->mem + offset;
>   }
>  
> - /* Store load address and source address of section */
> - sechdrs[i].sh_addr = curr_load_addr;
> + src = (void *)sechdrs[i].sh_offset;
> + dst = pi->purgatory_buf + offset;
> + memcpy(dst, src, sechdrs[i].sh_size);
> +
> + sechdrs[i].sh_addr = kbuf->mem + offset;
>  
>   /*
>* This section got copied to temporary buffer. Update
>* ->sh_offset accordingly.
>*/
> - sechdrs[i].sh_offset = (unsigned long)(buf_addr + offset);
> -
> - /* Advance to the next address */
> - curr_load_addr += sechdrs[i].sh_size;
> + sechdrs[i].sh_offset = (unsigned long)dst;
> + offset += sechdrs[i].sh_size;
>   }
>  
>   return 0;
> -- 
> 2.13.5
> 

Thanks
Dave

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

Re: [PATCH 09/11] kexec_file: Remove mis-use of sh_offset field

[Dave Young]

On 02/26/18 at 04:16pm, Philipp Rudo wrote:
> The current code uses the sh_offset field in purgatory_info->sechdrs to
> store a pointer to the current load address of the section. Depending
> whether the section will be loaded or not this is either a pointer into
> purgatory_info->purgatory_buf or kexec_purgatory. This is not only a
> violation of the ELF standard but also makes the code very hard to
> understand as you cannot tell if the memory you are using is read-only or
> not.
> 
> Remove this mis-use and store the offset of the section in
> pugaroty_info->purgatory_buf in sh_offset.
> 
> Signed-off-by: Philipp Rudo 
> ---
>  arch/x86/kernel/machine_kexec_64.c | 10 ++
>  kernel/kexec_file.c| 33 +++--
>  2 files changed, 9 insertions(+), 34 deletions(-)
> 
> diff --git a/arch/x86/kernel/machine_kexec_64.c 
> b/arch/x86/kernel/machine_kexec_64.c
> index 51667c8b5c9b..41db74bdc88b 100644
> --- a/arch/x86/kernel/machine_kexec_64.c
> +++ b/arch/x86/kernel/machine_kexec_64.c
> @@ -457,13 +457,15 @@ int arch_kexec_apply_relocations_add(struct 
> purgatory_info *pi,
>* rel[i].r_offset contains byte offset from beginning
>* of section to the storage unit affected.
>*
> -  * This is location to update (->sh_offset). This is temporary
> -  * buffer where section is currently loaded. This will finally
> -  * be loaded to a different address later, pointed to by
> +  * This is location to update. This is temporary buffer
> +  * where section is currently loaded. This will finally be
> +  * loaded to a different address later, pointed to by
>* ->sh_addr. kexec takes care of moving it
>*  (kexec_load_segment()).
>*/
> - location = (void *)(section->sh_offset + rel[i].r_offset);
> + location = pi->purgatory_buf;
> + location += section->sh_offset;
> + location += rel[i].r_offset;
>  
>   /* Final address of the location */
>   address = section->sh_addr + rel[i].r_offset;
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index 746b91e46e34..25b44d1a664a 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -736,28 +736,6 @@ static int kexec_purgatory_setup_sechdrs(struct 
> purgatory_info *pi,
>  pi->ehdr->e_shnum * sizeof(Elf_Shdr));
>   pi->sechdrs = sechdrs;
>  
> - /*
> -  * We seem to have multiple copies of sections. First copy is which
> -  * is embedded in kernel in read only section. Some of these sections
> -  * will be copied to a temporary buffer and relocated. And these
> -  * sections will finally be copied to their final destination at
> -  * segment load time.

It would be good to keep above part comment somewhere..

> -  *
> -  * Use ->sh_offset to reflect section address in memory. It will
> -  * point to original read only copy if section is not allocatable.
> -  * Otherwise it will point to temporary copy which will be relocated.
> -  *
> -  * Use ->sh_addr to contain final address of the section where it
> -  * will go during execution time.
> -  */
> - for (i = 0; i < pi->ehdr->e_shnum; i++) {
> - if (sechdrs[i].sh_type == SHT_NOBITS)
> - continue;
> -
> - sechdrs[i].sh_offset = (unsigned long)pi->ehdr +
> - sechdrs[i].sh_offset;
> - }
> -
>   offset = 0;
>   bss_addr = kbuf->mem + kbuf->bufsz;
>   kbuf->image->start = pi->ehdr->e_entry;
> @@ -786,17 +764,12 @@ static int kexec_purgatory_setup_sechdrs(struct 
> purgatory_info *pi,
>   kbuf->image->start += kbuf->mem + offset;
>   }
>  
> - src = (void *)sechdrs[i].sh_offset;
> + src = (void *)pi->ehdr + sechdrs[i].sh_offset;
>   dst = pi->purgatory_buf + offset;
>   memcpy(dst, src, sechdrs[i].sh_size);
>  
>   sechdrs[i].sh_addr = kbuf->mem + offset;
> -
> - /*
> -  * This section got copied to temporary buffer. Update
> -  * ->sh_offset accordingly.
> -  */
> - sechdrs[i].sh_offset = (unsigned long)dst;
> + sechdrs[i].sh_offset = offset;
>   offset += sechdrs[i].sh_size;
>   }
>  
> @@ -1006,7 +979,7 @@ int kexec_purgatory_get_set_symbol(struct kimage *image, 
> const char *name,
>   return -EINVAL;
>   }
>  
> - sym_buf = (char *)sec->sh_offset + sym->st_value;
> + sym_buf = (char *)pi->purgatory_buf + sec->sh_offset + sym->st_value;
>  
>   if (get_value)
>   memcpy((void *)buf, sym_buf, size);
> -- 
> 2.13.5
> 

Thanks
Dave

___
kexec mailing list

[PATCH] makedumpfile: fix for hugepages filtering

[Hari Bathini]

Kernel commit 036e7aa49fb2 changed 'compound_dtor' & 'compound_order'
types from 'unsigned short' to 'unsigned char'. Fix it here to ensure
hugepages are filtered properly.

Also, makedumpfile tool commit 484c6b18624 used 'int' type for 'dtor'
argument in 'isHugetlb' function. While this works in recent kernels
that use 'unsigned short/char' type for 'compound_dtor', it breaks
older kernels that used address of 'free_huge_page' as dtor. Fix it
by changing 'dtor' type.

Signed-off-by: Hari Bathini 
---
 makedumpfile.c |   30 --
 makedumpfile.h |1 +
 2 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/makedumpfile.c b/makedumpfile.c
index ed138d3..ac8483d 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -241,7 +241,7 @@ is_in_same_page(unsigned long vaddr1, unsigned long vaddr2)
 }
 
 static inline int
-isHugetlb(int dtor)
+isHugetlb(unsigned long dtor)
 {
 return ((NUMBER(HUGETLB_PAGE_DTOR) != NOT_FOUND_NUMBER)
&& (NUMBER(HUGETLB_PAGE_DTOR) == dtor))
@@ -5798,18 +5798,36 @@ __exclude_unnecessary_pages(unsigned long mem_map,
 * and PGMM_CACHED is a power of 2.
 */
if ((index_pg < PGMM_CACHED - 1) && isCompoundHead(flags)) {
-   if (order_offset)
-   compound_order = USHORT(pcache + SIZE(page) + 
order_offset);
+   unsigned long long addr =
+   (unsigned long long)(pcache + SIZE(page));
+
+   if (order_offset) {
+   if (info->kernel_version >=
+   KERNEL_VERSION(4, 16, 0)) {
+   compound_order =
+   UCHAR(addr + order_offset);
+   } else {
+   compound_order =
+   USHORT(addr + order_offset);
+   }
+   }
 
if (dtor_offset) {
/*
 * compound_dtor has been changed from the 
address of descriptor
 * to the ID of it since linux-4.4.
 */
-   if (info->kernel_version >= KERNEL_VERSION(4, 
4, 0)) {
-   compound_dtor = USHORT(pcache + 
SIZE(page) + dtor_offset);
+   if (info->kernel_version >=
+   KERNEL_VERSION(4, 16, 0)) {
+   compound_dtor =
+   UCHAR(addr + dtor_offset);
+   } else if (info->kernel_version >=
+  KERNEL_VERSION(4, 4, 0)) {
+   compound_dtor =
+   USHORT(addr + dtor_offset);
} else {
-   compound_dtor = ULONG(pcache + 
SIZE(page) + dtor_offset);
+   compound_dtor =
+   ULONG(addr + dtor_offset);
}
}
 
diff --git a/makedumpfile.h b/makedumpfile.h
index 01eece2..4cfad98 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -241,6 +241,7 @@ static inline int string_exists(char *s) { return (s ? TRUE 
: FALSE); }
 string_exists((char *)(B)) &&  \
(strncmp((char *)(A), (char *)(B), strlen((char *)(B))) == 0))
 
+#define UCHAR(ADDR)*((unsigned char *)(ADDR))
 #define USHORT(ADDR)   *((unsigned short *)(ADDR))
 #define UINT(ADDR) *((unsigned int *)(ADDR))
 #define ULONG(ADDR)*((unsigned long *)(ADDR))


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