[lkml]   [2001]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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" <>
    > > > > 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
    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:03    [W:0.025 / U:52.264 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site