Messages in this thread | | | Date | Thu, 10 Apr 2003 07:57:38 -0700 | From | "Martin J. Bligh" <> | Subject | Re: [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/
| |