lkml.org 
[lkml]   [2011]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/2] list.h: add debug version of list_empty
On 21/03/11 16:52 -0700, ext Andrew Morton wrote:
> On Tue, 15 Mar 2011 15:08:42 +0200
> Phil Carmody <ext-phil.2.carmody@nokia.com> wrote:
> > +int list_empty(const struct list_head *head)
> > +{
> > + if ((head->prev == LIST_POISON2) || (head->prev == LIST_POISON1))
> > + WARN(1, "list_empty performed on a node "
> > + "at %p removed from a list.\n", head);
> > + else
> > + WARN((head->prev == head) != (head->next == head),
> > + "list_empty corruption. %p<-%p->%p is half-empty.\n",
> > + head->prev, head, head->next);

> The second warning here is triggering maybe a hundred times from all
> over the place just when booting the kernel.
>
> Here's the first two:
>
> [ 64.295941] WARNING: at lib/list_debug.c:89 list_empty+0x79/0x85()
> [ 64.296129] list_empty corruption. ffff880255bcb788<-ffff880255bcb788->ffff88024c3a3c20 is half-empty.


OK, so the patch is working as expected. Perhaps my expectations were wrong.

Looking at list.h I was sure that lists should always be either circular or
poisoned both ends. The above is a rho-shape, this == prev.

Traditional list_empty() returns false on such a node, so it should be
possible to list_del() it. But then next->prev will be set to this->prev
which is this. So this will never be deleted from the list. That situation
rings warning bells in my head. Which I guess is what the patch was trying
to concretise.

I presume the above are x86_64, I'll see if I can get access to such a
machine in the next few days, or reproduce it on one of the architectures
I do have here.

Phil




\
 
 \ /
  Last update: 2011-03-22 11:19    [W:0.103 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site