[Crash-utility] [External Mail]Re: [PATCH] Fix a segfault in setup_ikconfig.
Dave Anderson
anderson at redhat.com
Wed Sep 18 13:32:22 UTC 2019
----- Original Message -----
> Hi Dave,
> 1. I'm requesting the arm64.c change as well. Because some chip makers would
> like to define their own section size bits in kernel config to support
> memory hotplug, which is not same as ARM64 default SECTION_SIZE_BITS value:
> 30, such as QCOM SDM8150 or 8250 borads. Although linux kernel maintain line
> still define default SECTION_SIZE_BITS value: 30 as section_size_bits for
> sparsemem. The patch has detailed descript in the email "[PATCH] Fix for the
> determination of the ARM64 SECTION_SIZE_BITS".
I never received an email with that header. Can you please resend the email with
the patch attached (i.e., not inlined)?
Thanks,
Dave
> 2. The output of "sys config" for my dumpfile has been uploaded, which shows
> the last line is empty. it occurs a segment fault when add the last empty
> line into ikconfig entry. I agree that the use of STRNEQ() is better than
> strncmp().
>
> Best regards,
> Qiwu
>
>
>
> -----Original Message-----
> From: Dave Anderson <anderson at redhat.com>
> Sent: Wednesday, September 18, 2019 3:22 AM
> To: 陈启武 <chenqiwu at xiaomi.com>
> Cc: crash-utility at redhat.com
> Subject: [External Mail]Re: [PATCH] Fix a segfault in setup_ikconfig.
>
>
>
> ----- Original Message -----
> >
> > Hi Anderson,
> > I want to introduce a patch to your crash tool project. It’s a bugfix
> > for a segfault in setup_ikconfig.
> > We add an ikconfig entry only if ent[0] != '#', it is not an advisable
> > condition because there is a potential segfault risk if ent is gibberish.
>
> Using your dumpfile that has the bogus "ent" string, can you show me what the
> output of "sys config" looks like?
>
> Dave
>
> > I explain the reproducing steps about this segfault case:
> > I try to apply the following patch to crash 7.2.6++ code for a test.
> > --- a/arm64.c
> > +++ b/arm64.c
> > @@ -32,6 +32,7 @@ static int verify_kimage_voffset(void); static void
> > arm64_calc_kimage_voffset(void); static void
> > arm64_calc_phys_offset(void); static void
> > arm64_calc_virtual_memory_ranges(void);
> > +static void arm64_get_section_size_bits(void);
> > static int arm64_kdump_phys_base(ulong *); static ulong
> > arm64_processor_speed(void); static void arm64_init_kernel_pgd(void);
> > @@ -375,7 +376,11 @@ arm64_init(int when)
> >
> > case POST_GDB:
> > arm64_calc_virtual_memory_ranges();
> > - machdep->section_size_bits = _SECTION_SIZE_BITS;
> > + arm64_get_section_size_bits();
> > + if (CRASHDEBUG(1)) {
> > + fprintf(fp, "SECTION_SIZE_BITS: %ld\n",
> > machdep->section_size_bits);
> > + }
> > +
> > if (!machdep->max_physmem_bits) {
> > if ((string =
> > pc->read_vmcoreinfo("NUMBER(MAX_PHYSMEM_BITS)"))) {
> > machdep->max_physmem_bits =
> > atol(string); @@ -1055,6 +1060,32 @@ arm64_calc_phys_offset(void)
> > fprintf(fp, "using %lx as phys_offset\n",
> > ms->phys_offset); }
> >
> > +/*
> > + * Determine SECTION_SIZE_BITS either by reading VMCOREINFO or the
> > +kernel
> > + * config, otherwise borrow the 64-bit ARM default definiton.
> > + */
> > +static void
> > +arm64_get_section_size_bits(void)
> > +{
> > + int ret;
> > + char *string;
> > +
> > + if ((string = pc->read_vmcoreinfo("NUMBER(SECTION_SIZE_BITS)"))) {
> > + machdep->section_size_bits = atol(string);
> > + free(string);
> > + return;
> > + }
> > +
> > + if ((ret = get_kernel_config("CONFIG_MEMORY_HOTPLUG", NULL))
> > + ==
> > IKCONFIG_Y) {
> > + if ((ret =
> > + get_kernel_config("CONFIG_HOTPLUG_SIZE_BITS",
> > &string)) == IKCONFIG_STR) {
> > + machdep->section_size_bits = atol(string);
> > + free(string);
> > + return;
> > + }
> > + } else {
> > + machdep->section_size_bits = _SECTION_SIZE_BITS;
> > + }
> > +}
> >
> > Then I make and load the dumpfiles by crash, it occurs a segment fault
> > as
> > below:
> > crash[31000]: segfault at 0 ip 00007f0fb24d98d1 sp 00007fff1703f7e8
> > error 4 in libc-2.26.so[7f0fb235b000+1d6000]
> >
> > So I add debug to find out the segfault reason, It occurred in
> > setup_ikconfig-> add_ikconfig_entry.
> > add_ikconfig_entry: ▒▒▒U //The last ent is a gibberish, lead
> > to segfault
> >
> > I think the most advisable judgement is if an ikconfig entry start
> > with "CONFIG_". I debug by the following patch and never reproduce
> > segfault again.
> > diff --git a/kernel.c b/kernel.c
> > index 7804aef..d023c87 100644
> > --- a/kernel.c
> > +++ b/kernel.c
> > @@ -10144,7 +10144,7 @@ static int setup_ikconfig(char *config)
> > while (whitespace(*ent))
> > ent++;
> >
> > - if (ent[0] != '#') {
> > + if (!strncmp(ent, "CONFIG_", strlen("CONFIG_"))) {
> > add_ikconfig_entry(ent,
> > &ikconfig_all[kt->ikconfig_ents++]);
> > if (kt->ikconfig_ents == IKCONFIG_MAX) {
> >
> > Thanks for your review. I’m looking forward to your favourable reply!
> >
> > Best regards,
> > Qiwu
> >
> >
> >
> >
> > #/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部
> > 或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> > This e-mail and its attachments contain confidential information from
> > XIAOMI, which is intended only for the person or entity whose address
> > is listed above. Any use of the information contained herein in any
> > way (including, but not limited to, total or partial disclosure,
> > reproduction, or dissemination) by persons other than the intended
> > recipient(s) is prohibited. If you receive this e-mail in error,
> > please notify the sender by phone or email immediately and delete
> > it!******/#
> >
> #/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from
> XIAOMI, which is intended only for the person or entity whose address is
> listed above. Any use of the information contained herein in any way
> (including, but not limited to, total or partial disclosure, reproduction,
> or dissemination) by persons other than the intended recipient(s) is
> prohibited. If you receive this e-mail in error, please notify the sender by
> phone or email immediately and delete it!******/#
>
More information about the Crash-utility
mailing list