On Sun, 21 Nov 2010, Andrew Case wrote:

> On Sun, Nov 21, 2010 at 4:45 AM, Robert P. J. Day <rpj...@crashcourse.ca> 
> wrote:
>
>        continuing my journey into the depths of kernel data structures, i'm
>       curious about the design and usage of list "poisoning".
>
>        first, here are the magic values used to poison list node pointers,
>       defined in poison.h:
>
>
>       #define LIST_POISON1  ((void *) 0x00100100 + POISON_POINTER_DELTA)
>       #define LIST_POISON2  ((void *) 0x00200200 + POISON_POINTER_DELTA)
>
>
>       doesn't really matter what those value are, they're just magic and
>       immediately identifiable values.  and they're used as the new values
>       for the prev and next pointers of list nodes that are, among other
>       things, removed from a list.  this is from list.h:
>
>
>
> examples of why the values are always set:
>
> http://lkml.org/lkml/2003/12/3/104
> http://lkml.org/lkml/2003/6/14/155
>
> even without debugging on, its still immediately obvious when a
> poisoned pointer is deferenced. And it does matter what the values
> are, they are set to addresses that won't normally be mapped in
> order to trigger a fault. This catches programming errors even when
> full debugging isn't enabled.

  ok, that makes sense.  it's not that other kernel code will
explicitly be checking for poison values, it's that just the normal
dereferencing will generate errors that will make it clear that
something like this has happened.  got it.  thanks.

rday

-- 

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Reply via email to