Re: Deadlock on the mm->mmap_sem

[Andrea Arcangeli]

On Thu, Sep 20, 2001 at 08:05:57AM +0100, David Howells wrote:
> 
> Andrea Arcangeli <[e-mail]> 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.

Andrea