[PATCH v2 6/8] makedumpfile: Read and process 'for' command from config file.
Ken'ichi Ohmichi
oomichi at mxs.nes.nec.co.jp
Wed Sep 7 02:41:15 EDT 2011
Hi Mahesh,
On Mon, 5 Sep 2011 20:10:33 +0530
Mahesh J Salgaonkar <mahesh at linux.vnet.ibm.com> wrote:
> > >
> > > This patch fixes following BUGs:
> >
> > [..]
> >
> > > - The loop construct used for array of char* (pointer) silently fails and
> > > does not filter the strings.
> >
> > Did the silent failure happen at the following code of list_entry_empty() ?
> >
> > 7373 addr = get_config_symbol_addr(le, 0, NULL);
> > 7374 if (!addr)
> > 7375 return TRUE;
> >
>
> Nope. It use to fail in resolve_list_entry()->resolve_config_entry()
> and following hunk from the patch fixes it:
>
> @@ -6866,7 +6882,7 @@ resolve_config_entry(struct config_entry *ce, unsigned long long base_addr,
> * If this is a struct or list_head data type then
> * create a leaf node entry with 'next' member.
> */
> - if ((ce->type_flag & TYPE_BASE)
> + if (((ce->type_flag & (TYPE_BASE | TYPE_ARRAY)) == TYPE_BASE)
> && (strcmp(ce->type_name, "void")))
> return FALSE;
>
> The old code use to check only TYPE_BASE flag ignoring TYPE_ARRAY flag.
Thank you for the explanation.
I feel I see it.
Is the below understanding right ?
At the part of earlier resolve_config_entry(), necessary information
(sym_addr, type_name, and array_length) can be gotten in the case
of pointer array.
However, the old resolve_config_entry() returned FALSE because of
the check lack you said.
Thanks
Ken'ichi Ohmichi
More information about the kexec
mailing list