RE: Segfault hidden in list.h

[Rose, Billy]

I'm not hitting it, but I came across it while writing an application server
based on TUX 2.1.0. I noticed that Ingo didn't lock a list during reads. As
long as his code traverses forward (which it does) all is well. If, however,
some module writer out there fails to lock a list for reads and traverses
said list in reverse, a failure could result. 

By logic design this assignment ordering eliminates the need for a read
lock, hence improving performance, not just data integrity.

Billy Rose 
[e-mail]

> -----Original Message-----
> From: Jeff Garzik [mailto:[e-mail]]
> Sent: Sunday, May 12, 2002 7:45 PM
> To: Rose, Billy
> Subject: Re: Segfault hidden in list.h
> 
> 
> Rose, Billy wrote:
> 
> >The code inside of __list_add:
> >
> >next->prev = new;
> >new->next = next;
> >new->prev = prev;
> >pre-next = new;
> >
> >needs to be altered to:
> >
> >new->prev = prev;
> >new->next = next;
> >next->prev = new;
> >prev->next = new;
> >
> >If something is accessing the list in reverse at the time of 
> insertion and
> >"next->prev = new;" has been executed, there exists a moment 
> when new->prev
> >may contain garbage if the element had been used in another 
> list and is
> >being transposed into a new one. Even if garbage is not 
> present, and the
> >element had just been initialized (i.e. new->prev = new), a 
> false list head
> >will appear briefly (from the executing thread's point of view).
> >
> 
> It sounds like you need better locking, if you are hitting this...
> 
>