Re: [Patch] shm bug introduced with pagecache in 2.3.11

Linus Torvalds (torvalds@transmeta.com)
Thu, 25 Nov 1999 09:20:57 -0800 (PST)


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/