On Sun, 23 Mar 2008, Manish Katiyar wrote:
> On Sun, Mar 23, 2008 at 7:01 PM, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
> > On Sun, 23 Mar 2008, Manish Katiyar wrote:
> >
> > ... snip ...
> >
> >
> > > > list_splice(&d->fifo_list, &packet_list);
> > > > list_splice(&d->pending_list, &packet_list);
> > > > INIT_LIST_HEAD(&d->fifo_list);
> > > > INIT_LIST_HEAD(&d->pending_list);
> > > > ...
> > >
> > > Interesting point Robert, I agree. However not every call to
> > > list_splice is accompanied by a call to INIT_LIST_HEAD in the
> > > current code (26.24.2) and I can see this *seem to be buggy* call in
> > > some of the important files like VM and cache. One such example is
> > > in
> > >
> > > kmem_cache_shrink
> > > shrink_page_list
> > >
> > > etc. and lot of others. Wonder how they work unless we are missing
> > > something :-)
> >
> > by the way, in some cases, there is a call to INIT_LIST_HEAD but it
> > might be a number of lines down in the code so sometimes it's not
> > obvious. i've noticed a couple of those.
> >
>
> Hmmm.... after seeing the list_del(), I was wondering if after
> splicing the list, what seems to be more reasonable.
>
> Setting the prev and next pointers of head to NULL, or setting them to
> LIST_POISON1 and LIST_POISON2 as these two seem to be the ideal
> candidate as they are made to notify(tracked easliy) in case of
> illegal access of list pointers.
>
> Robert your thoughts/comments ??
i noticed that, but i'm not sure what the purpose is behind
LIST_POISON{1,2}. if you grep the entire tree for LIST_POISON1, this
is what you get:
$ grep -rw LIST_POISON1 *
Documentation/scsi/ChangeLog.lpfc: removed (100100 is a LIST_POISON1
value from the next pointer
include/linux/list.h: entry->next = LIST_POISON1;
include/linux/list.h: n->next = LIST_POISON1;
include/linux/poison.h:#define LIST_POISON1 ((void *) 0x00100100)
lib/list_debug.c: entry->next = LIST_POISON1;
net/rxrpc/af_rxrpc.c: ASSERTCMP(rx->listen_link.next, !=, LIST_POISON1);
$
so, there's a doc file, a macro define, three assignments, and all
of *one* test deep in the bowels of rxrpc. that doesn't strike me as
being a compelling reason for existence. does anyone else have an
opinion on why poisoning link pointers has a purpose that's different
from just setting them to NULL? it's certainly not clear, is it?
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to [EMAIL PROTECTED]
Please read the FAQ at http://kernelnewbies.org/FAQ
