Re: Deadlock on the mm->mmap_sem

["Manfred Spraul" <manfred@colorfullife.com>]

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