Re: [PATCH v2 6/8] makedumpfile: Read and process 'for' command from config file.

From: Mahesh Jagannath Salgaonkar <mahesh@linux.vnet.ibm.com>
To: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>
Cc: V Srivatsa <vsrivatsa@in.ibm.com>,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	kexec@lists.infradead.org, Dave Anderson <anderson@redhat.com>,
	Prerna Saxena <prerna@linux.vnet.ibm.com>,
	Reinhard <BUENDGEN@de.ibm.com>
Subject: Re: [PATCH v2 6/8] makedumpfile: Read and process 'for' command from config file.
Date: Wed, 07 Sep 2011 16:44:06 +0530	[thread overview]
Message-ID: <4E6751FE.5070605@linux.vnet.ibm.com> (raw)
In-Reply-To: <20110907154115.02b47998.oomichi@mxs.nes.nec.co.jp>

Hi Ken'ichi,

On 09/07/2011 12:11 PM, Ken'ichi Ohmichi wrote:
> 
> Hi Mahesh,
> 
> On Mon, 5 Sep 2011 20:10:33 +0530
> Mahesh J Salgaonkar <mahesh@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:
>>We dont allow no-array 
>> @@ -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.

Yes, including the size information for type of element (type_name) in
the LIST entry.

> However, the old resolve_config_entry() returned FALSE because of
> the check lack you said.

Yes. The old resolve_config_entry() use to return FALSE only for array
of base type elements (e.g. array of char, int, long etc.). However, it
was working well for array of structures (pointer/non-pointer).

The LIST entry can be of one of the following kind:
1. Array of base types (pointer/non-pointer).
2. Array of structures (pointer/non-pointer).
3. Link list.
4. list_head link list.

The old code was working for all of the above except (1).

Thanks,
-Mahesh.

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