Messages in this thread |  | | From | "Manfred Spraul" <> | Subject | Re: Deadlock on the mm->mmap_sem | Date | Tue, 18 Sep 2001 09:31:40 +0200 |
| |
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.
> The fix is a few liner for my > implementation, here it is: >
Obivously your patch fixes the race, but we could starve down_write() if there are many page faults. Which multithreaded apps rely on mmap for file io? innd, perhaps samba if mmap is enabled (I'm not sure what's the default and if samba is multithreaded).
If you compile a kernel for 80386, then i386 uses the generic semaphores. Could someone with innd compile his kernel for i386, apply Andrea's patch and check that the performance doesn't break down?
IMHO modifying proc_pid_read_maps() is far simpler - I'm not aware of another recursive mmap_sem user. -- Manfred
- 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/
|  |