Messages in this thread | | | Date | Thu, 25 Nov 1999 09:20:57 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: [Patch] shm bug introduced with pagecache in 2.3.11 |
| |
On Thu, 25 Nov 1999, Andrea Arcangeli wrote: > > If you allow more than one task to fault for example in the swapin path > you'll get in troubles as you can't solve this race cleanly with a > spinlock. That's why I added the semaphore to the shm segments in first > place.
No, you can solve it cleanly by just changing the code: you only really need to guarantee that the mapping doesn't change under you (that would be disastrous and very hard to recover from). Somebody else filling in the page before you is simple to check for.
> Only replacing the down() with a read_down() in do_page_fault is _not_ > enough. The semaphore is not there only to protect from mmap and vma > changes under us, right now it's there mainly to protect other threads to > fault under us.
"mainly" is incorrect. The main protection is to maintain the vma list sanely, that was always the case (it used to be easy to crash the kernel by using threads that pagefaulted and mmap'ed at the same time).
Protecting against others paging in is trivial, and in fact we used to do that as long ago as 1.2.x if I remember correctly (the mm code was very different back then). The way we used to do that was to remember the original pte value, and before updating it with the newpage that was just paged in we just check that the pte value hasn't changed.
In 1.2.x that protected us against threads that paged in simultaneously, and the races introduced by the IO waiting. But it was not enough to protect against mmap's changing the vma, so we introduced the semaphore in 1.3.x, and because we had the semaphore we could also remove the optimistic checking.
In 2.3.x, we can use the same trivial approach to protect against threads. It adds basically no overhead at all - we have to get the spinlock anyway, and the final check before changing the page tables is basically a single load and compare.
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |