RE: Segfault hidden in list.h

[Rose, Billy]

I stand to correct myself further. Ingo has a wrapper function around a more
general purpose function, and the wrapper locks the list. All is good as
long as the general purpose function isn't called directly. My apologies to
Ingo for not scanning the code closer, the function names are almost
identical and I missed that...

Billy Rose 
[e-mail]

> -----Original Message-----
> From: Rose, Billy [mailto:[e-mail]]
> Sent: Sunday, May 12, 2002 8:10 PM
> To: 'Linus Torvalds'
> Cc: Kernel Mailing List
> Subject: RE: Segfault hidden in list.h
> 
> 
> I stand corrected. I guess my philosophy is for the long sought after
> "prefect world" example...
> 
> Cheers :)
> 
> Billy Rose 
> [e-mail]
> 
> > -----Original Message-----
> > From: Linus Torvalds [mailto:[e-mail]]
> > Sent: Sunday, May 12, 2002 7:59 PM
> > To: Rose, Billy
> > Cc: Kernel Mailing List
> > Subject: Re: Segfault hidden in list.h
> > 
> > 
> > 
> > 
> > On Sun, 12 May 2002, Rose, Billy wrote:
> > >
> > > 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
> > 
> > No.
> > 
> > If the coder doesn't lock his data structures, it doesn't 
> > matter _what_
> > order we execute the list modifications in - different 
> > architectures will
> > do different thing with inter-CPU memory ordering, and 
> trying to order
> > memory accesses on a source level is futile.
> > 
> > 		Linus
> > 
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to [e-mail]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>