[lkml]   [2010]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subjectshould list poisoning only kick in after selecting CONFIG_DEBUG_LIST?

a bit confused about list poisoning. there's this from

static inline void list_del(struct list_head *entry)
__list_del(entry->prev, entry->next);
entry->next = LIST_POISON1;
entry->prev = LIST_POISON2;
extern void list_del(struct list_head *entry);

which seems a bit weird since, even if you *don't* select
CONFIG_DEBUG_LIST, the deleted node's pointers are poisoned. why?
that's certainly being done in the debug version of list_del() in
lib/list_debug.c, but why is it also being done above? for what

and if i don't select that debugging option, should *anything* be
checking for those poison values?

$ grep -r -A2 LIST_POISON drivers
drivers/usb/host/xhci-hub.c: if (cmd-> != LIST_POISON1)
drivers/usb/host/xhci-hub.c- list_del(&cmd->cmd_list);
drivers/usb/host/xhci-hub.c- spin_unlock_irqrestore(&xhci->lock, flags);
drivers/usb/host/xhci.c: if (reset_device_cmd-> != LIST_POISON1)
drivers/usb/host/xhci.c- list_del(&reset_device_cmd->cmd_list);
drivers/usb/host/xhci.c- spin_unlock_irqrestore(&xhci->lock, flags);

that looks just plain odd. why would normal driver code that is not
dependent on CONFIG_DEBUG_LIST be checking for poison values? and if
it finds them, why is that not treated as that something has gone
significantly wrong, rather than quietly glossing over it?



Robert P. J. Day Waterloo, Ontario, CANADA


 \ /
  Last update: 2010-11-21 11:59    [W:0.065 / U:12.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site