Re: [PATCH] fix obj vma sorting

[Martin J. Bligh]

>> Yeah, sorry ... I guess someone should have published the phone
>> conversation we had yesterday ... </me pokes Dave in the eye>
>> 
>> We came to the conclusion that should be adding the semaphore to the
>> current  code even, as list_add_tail isn't atomic to a doubly linked list
>> (unless maybe you can do some fancy-pants compare and exchange thing
>> after setting up the prev pointer of the new element already). Which is
>> probably going to suck performance-wise, but I'd prefer correctness. From
>> there we can make a better judgment, but it sounds like it's going to
>> content horribly on those busy semaphores. 
> 
> I didn't publish the conversation because I realized that the semaphore is
> taken outside the function, so it is held.  It's what I called you back to
> tell you.

Oh yeah. I guess I should poke myself in the eye instead ;-)
So it's OK the way it is.
 
> I'm guessing the contention we're seeing with Hugh's fix is because of the
> way ld.so works.  It maps the entire library, then does an mprotect to
> change the idata section from shared to private.  It does this for every
> mapped library after every exec.

Eeek. There's no way we can set this up to do it as two separate VMAs
initially, is there?

M.