lkml.org 
[lkml]   [2003]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] fix obj vma sorting
>> 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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:34    [W:0.069 / U:1.956 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site