From: "Robert P. J. Day" <rpjday@crashcourse.ca>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: list splicing and list POISONing
Date: Tue, 25 Mar 2008 03:15:40 -0400 (EDT) [thread overview]
Message-ID: <alpine.LFD.1.00.0803250307110.29947@localhost.localdomain> (raw)
based on a conversation we've been having on the newbies list, i'm
curious about the rationale behind list "POISON"ing.
from <linux/list.h>, when you splice one list into another, the
head element from the original list is left hanging in space with its
original prev and next pointer values unchanged:
===
static inline void __list_splice(struct list_head *list,
struct list_head *head)
{
struct list_head *first = list->next;
struct list_head *last = list->prev;
struct list_head *at = head->next;
first->prev = head;
head->next = first;
last->next = at;
at->prev = last;
}
===
notice how neither list->prev nor list->next is set to, say, NULL to
represent that that list head now represents an empty list. instead,
those pointers are left (rather dangerously) pointing into the
newly-spliced list, which means that, if you erroneously try to
traverse the list represented by the "list" list head, you'll end up
immediately over in the new list and loop there forever. it would
seem to make more sense to set those pointers to either NULL or
LIST_POISON{1,2}, would it not? just for safety's sake?
it seems like that's what's done when an element is *deleted* (that
is, unlinked) from a list:
===
static inline void list_del(struct list_head *entry)
{
__list_del(entry->prev, entry->next);
entry->next = LIST_POISON1;
entry->prev = LIST_POISON2;
}
===
so shouldn't the same reasoning apply in the splicing example?
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
reply other threads:[~2008-03-25 7:15 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=alpine.LFD.1.00.0803250307110.29947@localhost.localdomain \
--to=rpjday@crashcourse.ca \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®