[lkml]   [2001]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Deadlock on the mm->mmap_sem
On Thu, Sep 20, 2001 at 08:05:57AM +0100, David Howells wrote:
> Andrea Arcangeli <> wrote:
> > yes, one solution to the latency problem without writing the
> > ugly code would be simply to add a per-process counter to pass to a
> > modified rwsem api, then to hide the trickery in a mm_down_read macro.
> > such way it will be recursive _and_ fair.
> You'd need a counter per-process per-mm_struct. Otherwise you couldn't do a
> recursive read lock simultaneously in two or more different processes, and
> also allow any one process to lock multiple mm_structs.

the process doesn't need to lock multiple mm_structs at the same time.

I mean, we just need to allow a single task to go through, doesn't
matter if the other tasks/threads are stuck, they will wait the write to
finish. that's exactly where the fairness cames from.

The only thing that matters is that if a certain task passes the first
read lock of its mmstruct semaphore, it will also pass any other
further recursive lock again of its own _same_ mmstruct. So a
per-process recursor is all what we need.

Must not be per-mm, per-mm would work but it would simply introduce the
unfairness again.

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.109 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site