Messages in this thread |  | | Date | Tue, 18 Sep 2001 10:49:38 +0100 | From | Arjan van de Ven <> | Subject | Re: Deadlock on the mm->mmap_sem |
| |
Andrea Arcangeli wrote: > > On Tue, Sep 18, 2001 at 09:31:40AM +0200, Manfred Spraul wrote: > > From: "Andrea Arcangeli" <andrea@suse.de> > > > > The mmap semaphore is a read-write semaphore, and it _is_ > > permissible to > > > > call "copy_to_user()" and friends while holding the read lock. > > > > > > > > The bug appears to be in the implementation of the write semaphore - > > > > down_write() doesn't undestand that blocked writes must not block > > new > > > > readers, exactly because of this situation. > > > > > > Exactly, same reason for which we need the same property from the rw > > > spinlocks (to be allowed to read_lock without clearing irqs). Thanks > > so > > > much for reminding me about this! Unfortunately my rwsemaphores are > > > blocking readers at the first down_write (for the better fairness > > > property issuse, but I obviously forgotten that doing so I would > > > introduce such a deadlock). > > > > i386 has a fair rwsemaphore, too - probably other archs must be modified > > as well. > > yes, actually my patch was against the rwsem patch in -aa, and in -aa > I'm using the generic semaphores for all archs in the tree so it fixes > the race for all them. The mainline semaphores are slightly different.
> if that's the very only place that could be a viable option but OTOH I > like to be allowed to use recursion on the read locks as with the > spinlocks. I think another option would be to have reacursion allowed on > the default read locks and then make a down_read_fair that will block at > if there's a down_write under us. we can very cleanly implement this, > the same can be done cleanly also for the spinlocks: read_lock_fair. One > can even mix the read_lock/read_lock_fair or the > down_read/down_read_fair together. For example assuming we use the > recursive semaphore fix in proc_pid_read_maps the down_read over there > could be converted to a down_read_fair (but that's just an exercise, if > the page fault isn't fair it doesn't worth to have proc_pid_read_maps > fair either).
Be careful; If another user can grab your semaphore for read for a short time (eg for "top" or similar usage), he can construct several threads that do this in a busy loop; the end result is that this evil user is capable of blocking out writers FOREVER if semaphores are unfair; nice DoS.... - 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/
|  |