[lkml]   [2001]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Deadlock on the mm->mmap_sem
From: "Andrea Arcangeli" <>
> > 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
> > 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
> 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

If you compile a kernel for 80386, then i386 uses the generic
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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:03    [W:0.062 / U:0.344 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site