[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