RE: [PATCH] makedumpfile/arm64: Add '--mem-usage' support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Bhupesh,

Thank you for your explanation.
It sounds good.
I will wait for your new patch.

Thanks
Tachibana


> -----Original Message-----
> From: Bhupesh Sharma [mailto:bhsharma@xxxxxxxxxx]
> Sent: Monday, March 05, 2018 12:41 PM
> To: Tachibana Masaki() <mas-tachibana@xxxxxxxxxxxxx>
> Cc: kexec@xxxxxxxxxxxxxxxxxxx; Hayashi Masahiko() <mas-hayashi@xxxxxxxxxxxxx>
> Subject: Re: [PATCH] makedumpfile/arm64: Add '--mem-usage' support
> 
> Hello Masaki,
> 
> Thanks for your reply.
> 
> On Fri, Mar 2, 2018 at 11:01 AM, Masaki Tachibana
> <mas-tachibana@xxxxxxxxxxxxx> wrote:
> > Hi Bhupesh,
> >
> > Sorry for the late reply.
> > And thank you for your patch.
> > I have some questions. Please answer me.
> > - Have you succeeded --mem-usage on ppc64, s390x ?
> 
> Yes, --mem-usage works fine on both ppc64 and s390x RHEL systems
> for me. I tested the same on several ppc64 and s390x machines.
> 
> > - By your patch, makedumpfile behaves like this;
> >   1.Gets an address of _stext from a vmlinux file.
> >   2.Checks how many upper bits are 1 in the address.
> >   3.Determines va_bits and info->page_offset by the check.
> >   Isn't there any other method to get page_offset without a vmlinux ?
> 
> Ok, let me give some background here:
> 
> On ARM64 platforms the VA_BITS supported by a linux kernel run can be
> selected by setting 'ARM64_VA_BITS_*' (please see [1]) config options.
> 
> Now, to determine the 'info->page_offset' in arm64 makedumpfile
> context ('arch/arm64.c')
> we need to determine the VA_BITS which was selected by the underlying
> linux kernel.
> 
> Now there are several ways to determine the VA_BITS:
> 
> (a). Read the CONFIG flags from the user space using something like:
> - Create a 'running.config' which will contain the configuration of
> the running linux kernel
> and grep the VA_BITS from 'running.config' :
> # cat /proc/config.gz | gunzip > running.config
> - However this is only possible if running linux kernel was configured
> to have '/proc/config.gz'
> 
> So, this is probably not a good option.
> 
> (b). Read '_stext' symbol and calculate the 'va_bits' and
> 'info->page_offset' using the upper bits are 1 in the address.
> There are a couple of ways to do the same via makedumpfile code:
> - Use the 'vmlinux' file, which this version of the patch does.
> - Use the '/proc/kallsyms' file, which is also possible and I have a
> patch ready for this approach as well.
> 
> The '/proc/kallsyms' file approach is better in the following aspects:
> - We don't need to pass the 'vmlinux' file path separately while
> invoking '--mem-usage' option for makedumpfile.
> - It also helps the arm64 KASLR makedumpfile implementation (which I
> am currently working on and will send out a patch to address the same
> soon), as the '_stext' symbol will be randomized and hence cannot be
> properly read from the 'vmlinux' file.
> 
> If you agree, I can send a new version which reads the '_stext' symbol
> from '/proc/kallsyms' and works fine on the arm64 platforms I have
> tested it on (both with KASLR turned on and off)
> 
> [1]. https://elixir.bootlin.com/linux/v4.9/source/arch/arm64/Kconfig#L518
> Regards,
> Bhupesh
> 
> 
> > Thanks
> > Tachibana
> >
> >> -----Original Message-----
> >> From: kexec [mailto:kexec-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Bhupesh SHARMA
> >> Sent: Thursday, February 22, 2018 3:58 AM
> >> To: Tachibana Masaki() <mas-tachibana@xxxxxxxxxxxxx>
> >> Cc: kexec@xxxxxxxxxxxxxxxxxxx; Bhupesh Sharma <bhsharma@xxxxxxxxxx>; Hayashi Masahiko()
> >> <mas-hayashi@xxxxxxxxxxxxx>
> >> Subject: Re: [PATCH] makedumpfile/arm64: Add '--mem-usage' support
> >>
> >> Hi Masaki Tachibana,
> >>
> >> On Tue, Feb 20, 2018 at 4:42 PM, Masaki Tachibana
> >> <mas-tachibana@xxxxxxxxxxxxx> wrote:
> >> > Hi Bhupesh,
> >> >
> >> > Sorry for the late reply.
> >> > I'll reply by the end the next week.
> >>
> >> Sure. Thanks for your mail.
> >>
> >> Regards,
> >> Bhupesh
> >>
> >>
> >> > Thanks
> >> > tachibana
> >> >
> >> >> -----Original Message-----
> >> >> From: Bhupesh Sharma [mailto:bhsharma@xxxxxxxxxx]
> >> >> Sent: Tuesday, February 20, 2018 1:56 PM
> >> >> To: kexec@xxxxxxxxxxxxxxxxxxx
> >> >> Cc: Bhupesh Sharma <bhsharma@xxxxxxxxxx>; Tachibana Masaki() <mas-tachibana@xxxxxxxxxxxxx>; Nakayama Takuya(
> >> >> ) <tak-nakayama@xxxxxxxxxxxxx>; Nishimura Daisuke() <dai-nishimura@xxxxxxxxxxxxx>
> >> >> Subject: Re: [PATCH] makedumpfile/arm64: Add '--mem-usage' support
> >> >>
> >> >> Hello,
> >> >>
> >> >> On Fri, Feb 9, 2018 at 3:06 PM, Bhupesh Sharma <bhsharma@xxxxxxxxxx> wrote:
> >> >> > Its good to have the makedumpfile '--mem-usage' support
> >> >> > for arm64 architecture as well, as it allows one to see the page numbers
> >> >> > of current system (1st kernel) in different use.
> >> >> >
> >> >> > Using this we can know how many pages are dumpable when different
> >> >> > dump_level is specified.
> >> >> >
> >> >> > Normally for x86_64, makedumpfile analyzes the 'System Ram' and
> >> >> > 'kernel text' program segment of /proc/kcore excluding
> >> >> > the crashkernel range, then calculates the page number of different
> >> >> > kind per vmcoreinfo.
> >> >> >
> >> >> > We use the similar logic for arm64, but in addition make the '--mem-usage'
> >> >> > usage dependent on the VMLINUX file being passed. This is done to allow
> >> >> > information like VA_BITS being determined from kernel symbol like
> >> >> > _stext. This allows us to get the VA_BITS before 'set_kcore_vmcoreinfo()'
> >> >> > is called.
> >> >> >
> >> >> > Also I have validated the '--mem-usage' makedumpfile option on several
> >> >> > ppc64/ppc64le and s390x machines, so update the makedumpfile.8
> >> >> > documentation to indicate that '--mem-usage' option is supported
> >> >> > not only on x86_64, but also on ppc64, s390x and arm64.
> >> >> >
> >> >> > After this patch, when using the '--mem-usage' option with makedumpfile,
> >> >> > we get the correct information about the different pages. For e.g.
> >> >> > here is an output from my arm64 board:
> >> >> >
> >> >> > TYPE            PAGES                   EXCLUDABLE      DESCRIPTION
> >> >> > ----------------------------------------------------------------------
> >> >> > ZERO            49524                   yes             Pages filled with zero
> >> >> > NON_PRI_CACHE   15143                   yes             Cache pages without private flag
> >> >> > PRI_CACHE       29147                   yes             Cache pages with private flag
> >> >> > USER            3684                    yes             User process pages
> >> >> > FREE            1450569                 yes             Free pages
> >> >> > KERN_DATA       14243                   no              Dumpable kernel data
> >> >> >
> >> >> > page size:              65536
> >> >> > Total pages on system:  1562310
> >> >> > Total size on system:   102387548160     Byte
> >> >> >
> >> >> > Cc: Masaki Tachibana <mas-tachibana@xxxxxxxxxxxxx>
> >> >> > Cc: Takuya Nakayama <tak-nakayama@xxxxxxxxxxxxx>
> >> >> > Cc: Daisuke Nishimura <dai-nishimura@xxxxxxxxxxxxx>
> >> >> > Signed-off-by: Bhupesh Sharma <bhsharma@xxxxxxxxxx>
> >> >>
> >> >> Ping. Any review comments on this?
> >> >>
> >> >> Regards,
> >> >> Bhupesh
> >> >>
> >> >> > ---
> >> >> >  arch/arm64.c   | 51 ++++++++++++++++++++++++++++++++++++++++++++++++---
> >> >> >  makedumpfile.8 | 11 +++++++++--
> >> >> >  makedumpfile.c | 25 +++++++++++++++++++++++--
> >> >> >  makedumpfile.h |  1 +
> >> >> >  4 files changed, 81 insertions(+), 7 deletions(-)
> >> >> >
> >> >> > diff --git a/arch/arm64.c b/arch/arm64.c
> >> >> > index 25d7a1f4db98..91f113f6447c 100644
> >> >> > --- a/arch/arm64.c
> >> >> > +++ b/arch/arm64.c
> >> >> > @@ -48,6 +48,12 @@ static unsigned long kimage_voffset;
> >> >> >  #define SZ_64K                 (64 * 1024)
> >> >> >  #define SZ_128M                        (128 * 1024 * 1024)
> >> >> >
> >> >> > +#define PAGE_OFFSET_36 ((0xffffffffffffffffUL) << 36)
> >> >> > +#define PAGE_OFFSET_39 ((0xffffffffffffffffUL) << 39)
> >> >> > +#define PAGE_OFFSET_42 ((0xffffffffffffffffUL) << 42)
> >> >> > +#define PAGE_OFFSET_47 ((0xffffffffffffffffUL) << 47)
> >> >> > +#define PAGE_OFFSET_48 ((0xffffffffffffffffUL) << 48)
> >> >> > +
> >> >> >  #define pgd_val(x)             ((x).pgd)
> >> >> >  #define pud_val(x)             (pgd_val((x).pgd))
> >> >> >  #define pmd_val(x)             (pud_val((x).pud))
> >> >> > @@ -140,8 +146,6 @@ pud_offset(pgd_t *pgda, pgd_t *pgdv, unsigned long vaddr)
> >> >> >
> >> >> >  static int calculate_plat_config(void)
> >> >> >  {
> >> >> > -       va_bits = NUMBER(VA_BITS);
> >> >> > -
> >> >> >         /* derive pgtable_level as per arch/arm64/Kconfig */
> >> >> >         if ((PAGESIZE() == SZ_16K && va_bits == 36) ||
> >> >> >                         (PAGESIZE() == SZ_64K && va_bits == 42)) {
> >> >> > @@ -188,7 +192,6 @@ get_machdep_info_arm64(void)
> >> >> >         kimage_voffset = NUMBER(kimage_voffset);
> >> >> >         info->max_physmem_bits = PHYS_MASK_SHIFT;
> >> >> >         info->section_size_bits = SECTIONS_SIZE_BITS;
> >> >> > -       info->page_offset = 0xffffffffffffffffUL << (va_bits - 1);
> >> >> >
> >> >> >         DEBUG_MSG("kimage_voffset   : %lx\n", kimage_voffset);
> >> >> >         DEBUG_MSG("max_physmem_bits : %lx\n", info->max_physmem_bits);
> >> >> > @@ -219,6 +222,48 @@ get_xen_info_arm64(void)
> >> >> >  int
> >> >> >  get_versiondep_info_arm64(void)
> >> >> >  {
> >> >> > +       unsigned long long stext;
> >> >> > +
> >> >> > +       /* We can read the _stext symbol from vmlinux and determine the
> >> >> > +        * VA_BITS and page_offset.
> >> >> > +        */
> >> >> > +
> >> >> > +       /* Open the vmlinux file */
> >> >> > +       open_kernel_file();
> >> >> > +       set_dwarf_debuginfo("vmlinux", NULL,
> >> >> > +                       info->name_vmlinux, info->fd_vmlinux);
> >> >> > +
> >> >> > +       if (!get_symbol_info())
> >> >> > +               return FALSE;
> >> >> > +
> >> >> > +       /* Get the '_stext' symbol */
> >> >> > +       if (SYMBOL(_stext) == NOT_FOUND_SYMBOL) {
> >> >> > +               ERRMSG("Can't get the symbol of _stext.\n");
> >> >> > +               return FALSE;
> >> >> > +       } else {
> >> >> > +               stext = SYMBOL(_stext);
> >> >> > +       }
> >> >> > +
> >> >> > +       /* Derive va_bits as per arch/arm64/Kconfig */
> >> >> > +       if ((stext & PAGE_OFFSET_36) == PAGE_OFFSET_36) {
> >> >> > +               va_bits = 36;
> >> >> > +       } else if ((stext & PAGE_OFFSET_39) == PAGE_OFFSET_39) {
> >> >> > +               va_bits = 39;
> >> >> > +       } else if ((stext & PAGE_OFFSET_42) == PAGE_OFFSET_42) {
> >> >> > +               va_bits = 42;
> >> >> > +       } else if ((stext & PAGE_OFFSET_47) == PAGE_OFFSET_47) {
> >> >> > +               va_bits = 47;
> >> >> > +       } else if ((stext & PAGE_OFFSET_48) == PAGE_OFFSET_48) {
> >> >> > +               va_bits = 48;
> >> >> > +       } else {
> >> >> > +               ERRMSG("Cannot find a proper _stext for calculating VA_BITS\n");
> >> >> > +               return FALSE;
> >> >> > +       }
> >> >> > +
> >> >> > +       info->page_offset = (0xffffffffffffffffUL) << (va_bits - 1);
> >> >> > +
> >> >> > +       DEBUG_MSG("page_offset=%lx, va_bits=%d\n", info->page_offset, va_bits);
> >> >> > +
> >> >> >         return TRUE;
> >> >> >  }
> >> >> >
> >> >> > diff --git a/makedumpfile.8 b/makedumpfile.8
> >> >> > index 15db7947d62f..be9620035316 100644
> >> >> > --- a/makedumpfile.8
> >> >> > +++ b/makedumpfile.8
> >> >> > @@ -593,7 +593,7 @@ last cleared on the crashed kernel, through "dmesg --clear" for example.
> >> >> >
> >> >> >  .TP
> >> >> >  \fB\-\-mem-usage\fR
> >> >> > -This option is only for x86_64.
> >> >> > +This option is currently supported on x86_64, arm64, ppc64 and s390x.
> >> >> >  This option is used to show the page numbers of current system in different
> >> >> >  use. It should be executed in 1st kernel. By the help of this, user can know
> >> >> >  how many pages is dumpable when different dump_level is specified. It analyzes
> >> >> > @@ -601,12 +601,19 @@ the 'System Ram' and 'kernel text' program segment of /proc/kcore excluding
> >> >> >  the crashkernel range, then calculates the page number of different kind per
> >> >> >  vmcoreinfo. So currently /proc/kcore need be specified explicitly.
> >> >> >
> >> >> > +For arm64, path to vmlinux file should be specified as well.
> >> >> > +
> >> >> >  .br
> >> >> > -.B Example:
> >> >> > +.B Example (for architectures other than arm64):
> >> >> >  .br
> >> >> >  # makedumpfile \-\-mem-usage /proc/kcore
> >> >> > +
> >> >> > +.br
> >> >> > +.B Example (for arm64 architecture):
> >> >> >  .br
> >> >> >
> >> >> > +# makedumpfile \-\-mem-usage vmlinux /proc/kcore
> >> >> > +.br
> >> >> >
> >> >> >  .TP
> >> >> >  \fB\-\-diskset=VMCORE\fR
> >> >> > diff --git a/makedumpfile.c b/makedumpfile.c
> >> >> > index ed138d339d9a..b38b5000aa74 100644
> >> >> > --- a/makedumpfile.c
> >> >> > +++ b/makedumpfile.c
> >> >> > @@ -11090,7 +11090,14 @@ static struct option longopts[] = {
> >> >> >         {"cyclic-buffer", required_argument, NULL, OPT_CYCLIC_BUFFER},
> >> >> >         {"eppic", required_argument, NULL, OPT_EPPIC},
> >> >> >         {"non-mmap", no_argument, NULL, OPT_NON_MMAP},
> >> >> > +#ifdef __aarch64__
> >> >> > +       /* VMLINUX file is required for aarch64 for get
> >> >> > +        * the symbols required to calculate va_bits.
> >> >> > +        */
> >> >> > +       {"mem-usage", required_argument, NULL, OPT_MEM_USAGE},
> >> >> > +#else
> >> >> >         {"mem-usage", no_argument, NULL, OPT_MEM_USAGE},
> >> >> > +#endif
> >> >> >         {"splitblock-size", required_argument, NULL, OPT_SPLITBLOCK_SIZE},
> >> >> >         {"work-dir", required_argument, NULL, OPT_WORKING_DIR},
> >> >> >         {"num-threads", required_argument, NULL, OPT_NUM_THREADS},
> >> >> > @@ -11201,8 +11208,22 @@ main(int argc, char *argv[])
> >> >> >                         info->flag_partial_dmesg = 1;
> >> >> >                         break;
> >> >> >                 case OPT_MEM_USAGE:
> >> >> > -                      info->flag_mem_usage = 1;
> >> >> > -                      break;
> >> >> > +                       info->flag_mem_usage = 1;
> >> >> > +#ifdef __aarch64__
> >> >> > +                       /* VMLINUX file is required for aarch64 for get
> >> >> > +                        * the symbols required to calculate va_bits and
> >> >> > +                        * it should be the 1st command parameter being
> >> >> > +                        * specified.
> >> >> > +                        */
> >> >> > +                       if (strcmp(optarg, "/proc/kcore") == 0) {
> >> >> > +                               MSG("vmlinux path should be 1st commandline parameter with --mem-usage option.\n");
> >> >> > +                               goto out;
> >> >> > +                       }
> >> >> > +                       else {
> >> >> > +                               info->name_vmlinux = optarg;
> >> >> > +                       }
> >> >> > +#endif
> >> >> > +                       break;
> >> >> >                 case OPT_COMPRESS_SNAPPY:
> >> >> >                         info->flag_compress = DUMP_DH_COMPRESSED_SNAPPY;
> >> >> >                         break;
> >> >> > diff --git a/makedumpfile.h b/makedumpfile.h
> >> >> > index 01eece231475..f65d91870b73 100644
> >> >> > --- a/makedumpfile.h
> >> >> > +++ b/makedumpfile.h
> >> >> > @@ -2308,6 +2308,7 @@ struct elf_prstatus {
> >> >> >  /*
> >> >> >   * Function Prototype.
> >> >> >   */
> >> >> > +int open_kernel_file(void);
> >> >> >  mdf_pfn_t get_num_dumpable_cyclic(void);
> >> >> >  mdf_pfn_t get_num_dumpable_cyclic_withsplit(void);
> >> >> >  int get_loads_dumpfile_cyclic(void);
> >> >> > --
> >> >> > 2.7.4
> >> >> >
> >> >
> >> > _______________________________________________
> >> > kexec mailing list
> >> > kexec@xxxxxxxxxxxxxxxxxxx
> >> > http://lists.infradead.org/mailman/listinfo/kexec
> >>
> >> _______________________________________________
> >> kexec mailing list
> >> kexec@xxxxxxxxxxxxxxxxxxx
> >> http://lists.infradead.org/mailman/listinfo/kexec
> >
> >

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



[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux