All of lore.kernel.org
 help / color / mirror / Atom feed
* [Ocfs2-devel] ocfs2: bug in dlm_process_recovery_data()
@ 2010-02-09  8:09 Dan Carpenter
  2010-02-09 17:53 ` Sunil Mushran
  0 siblings, 1 reply; 4+ messages in thread
From: Dan Carpenter @ 2010-02-09  8:09 UTC (permalink / raw)
  To: ocfs2-devel

I noticed a change was merged to dlm_process_recovery_data() so I 
thought you might want to fix this as well.

fs/ocfs2/dlm/dlmrecovery.c
  1788                                  list_for_each_entry(lock, tmpq, list) {
  1789                                          if (lock->ml.cookie != ml->cookie)
  1790                                                  lock = NULL;

	We dereference lock in list_for_each_entry().  Maybe you want 
	list_for_each_entry_safe() or something?

  1791                                          else
  1792                                                  break;
  1793                                  }
  1794                                  if (lock)
  1795                                          break;

regards,
dan carpenter

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Ocfs2-devel] ocfs2: bug in dlm_process_recovery_data()
  2010-02-09  8:09 [Ocfs2-devel] ocfs2: bug in dlm_process_recovery_data() Dan Carpenter
@ 2010-02-09 17:53 ` Sunil Mushran
  2010-02-10 10:01   ` Dan Carpenter
  0 siblings, 1 reply; 4+ messages in thread
From: Sunil Mushran @ 2010-02-09 17:53 UTC (permalink / raw)
  To: ocfs2-devel

Dan Carpenter wrote:
> I noticed a change was merged to dlm_process_recovery_data() so I 
> thought you might want to fix this as well.
>
> fs/ocfs2/dlm/dlmrecovery.c
>   1788                                  list_for_each_entry(lock, tmpq, list) {
>   1789                                          if (lock->ml.cookie != ml->cookie)
>   1790                                                  lock = NULL;
>
> 	We dereference lock in list_for_each_entry().  Maybe you want 
> 	list_for_each_entry_safe() or something?
>
>   1791                                          else
>   1792                                                  break;
>   1793                                  }
>   1794                                  if (lock)
>   1795                                          break;
>   

Why? That's only required if we are deleting a list entry.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Ocfs2-devel] ocfs2: bug in dlm_process_recovery_data()
  2010-02-09 17:53 ` Sunil Mushran
@ 2010-02-10 10:01   ` Dan Carpenter
  2010-02-10 18:37     ` Sunil Mushran
  0 siblings, 1 reply; 4+ messages in thread
From: Dan Carpenter @ 2010-02-10 10:01 UTC (permalink / raw)
  To: ocfs2-devel

On Tue, Feb 09, 2010 at 09:53:01AM -0800, Sunil Mushran wrote:
> Dan Carpenter wrote:
>> I noticed a change was merged to dlm_process_recovery_data() so I  
>> thought you might want to fix this as well.
>>
>> fs/ocfs2/dlm/dlmrecovery.c
>>   1788                                  list_for_each_entry(lock, tmpq, list) {
>>   1789                                          if (lock->ml.cookie != ml->cookie)
>>   1790                                                  lock = NULL;
>>
>> 	We dereference lock in list_for_each_entry().  Maybe you want  
>> 	list_for_each_entry_safe() or something?
>>
>>   1791                                          else
>>   1792                                                  break;
>>   1793                                  }
>>   1794                                  if (lock)
>>   1795                                          break;
>>   
>
> Why? That's only required if we are deleting a list entry.

list_for_each() is defined in include/linux/list.h

/**
 * list_for_each_entry  -       iterate over list of given type
 * @pos:        the type * to use as a loop cursor.
 * @head:       the head for your list.
 * @member:     the name of the list_struct within the struct.
 */
#define list_for_each_entry(pos, head, member)                          \
        for (pos = list_entry((head)->next, typeof(*pos), member);      \
             prefetch(pos->member.next), &pos->member != (head);        \
             pos = list_entry(pos->member.next, typeof(*pos), member))
                              ^^^^^^^^^^^^^^^^

In this case "pos" is "lock" so the code basically is doing this:
lock = NULL;
lock = list_entry(lock->member.next, typeof(*lock), member));
                  ^^^^^^^^^^^^^^^^^
regards,
dan carpenter

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Ocfs2-devel] ocfs2: bug in dlm_process_recovery_data()
  2010-02-10 10:01   ` Dan Carpenter
@ 2010-02-10 18:37     ` Sunil Mushran
  0 siblings, 0 replies; 4+ messages in thread
From: Sunil Mushran @ 2010-02-10 18:37 UTC (permalink / raw)
  To: ocfs2-devel

Dan Carpenter wrote:
> In this case "pos" is "lock" so the code basically is doing this:
> lock = NULL;
> lock = list_entry(lock->member.next, typeof(*lock), member));
>                   ^^^^^^^^^^^^^^^^^
>   

Yes, you are correct. The reason it is working is because the resource
will have only one lock on the list. This is the remastery code. I'll 
fix it.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2010-02-10 18:37 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-02-09  8:09 [Ocfs2-devel] ocfs2: bug in dlm_process_recovery_data() Dan Carpenter
2010-02-09 17:53 ` Sunil Mushran
2010-02-10 10:01   ` Dan Carpenter
2010-02-10 18:37     ` Sunil Mushran

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.