All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mahesh J 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: Mon, 5 Sep 2011 20:10:33 +0530	[thread overview]
Message-ID: <20110905144033.GA26767@in.ibm.com> (raw)
In-Reply-To: <20110901170658.67f830df.oomichi@mxs.nes.nec.co.jp>

Hi Ken'ichi,

On 2011-09-01 17:06:58 Thu, Ken'ichi Ohmichi wrote:
> 
> Hi Mahesh,
> 
> Thank you for the patch.
> I have one question.
> 
> On Tue, 30 Aug 2011 23:46:42 +0530
> Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com> wrote:
> > 
> > [PATCH] makedumpfile: Fix array traversal for array of structure and char type.
> > 
> > From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
> > 
> > Introduce new function get_next_list_entry() that returns config entry
> > for each element in the LIST entry. This approach improves the handling
> > of LIST entry. With this change the function get_config_symbol_addr()
> > no longer required to handle LIST entry separately.
> > 
> > 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.

> If list_entry_empty() returns TRUE, a "while" loop of process_config() breaks
> and update_filter_info() is not called.
> Is that the problem you said ?
> 
> If yes, I feel the behavior related with this problem has not changed.
> because the method for getting a pointer array has not changed like the
> following:

The while loop below still holds good as it just ignores the pointer array
elements which are NULL pointers and we dont have anything to be erased for
NULL pointers.

> 
> o OLD
>     111 -                               while (ce->index < ce->array_length) {
>     112 -                                       addr = read_pointer_value(ce->addr +
>     113 -                                               (ce->index * get_pointer_size()));
>     114 -                                       ce->index++;
>     115 -                                       if (addr)
>     116 -                                               break;
>     117 -                               }
>     118 -                               return addr;
> 
> o NEW
>     197 +                               while (ce->index < ce->array_length) {
>     198 +                                       addr = read_pointer_value(ce->addr +
>     199 +                                               (ce->index * get_pointer_size()));
>     200 +                                       if (addr)
>     201 +                                               break;
>     202 +                                       ce->index++;
>     203 +                               }
>     204 +                               if (ce->index == ce->array_length)
>     205 +                                       return FALSE;
> 
> 
> I think the other bugfixes are right, thanks.
> 
> 
> Thanks
> Ken'ichi Ohmichi
> 

Thanks,
-Mahesh.


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

  reply	other threads:[~2011-09-05 14:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-17 20:05 [PATCH v2 6/8] makedumpfile: Read and process 'for' command from config file Mahesh J Salgaonkar
2011-08-11  8:06 ` Ken'ichi Ohmichi
2011-08-30 18:16   ` Mahesh J Salgaonkar
2011-09-01  8:06     ` Ken'ichi Ohmichi
2011-09-05 14:40       ` Mahesh J Salgaonkar [this message]
2011-09-07  6:41         ` Ken'ichi Ohmichi
2011-09-07 11:14           ` Mahesh Jagannath Salgaonkar
2011-09-07 23:35             ` Ken'ichi Ohmichi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110905144033.GA26767@in.ibm.com \
    --to=mahesh@linux.vnet.ibm.com \
    --cc=BUENDGEN@de.ibm.com \
    --cc=ananth@in.ibm.com \
    --cc=anderson@redhat.com \
    --cc=kexec@lists.infradead.org \
    --cc=oomichi@mxs.nes.nec.co.jp \
    --cc=prerna@linux.vnet.ibm.com \
    --cc=vsrivatsa@in.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.