public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: Linus Torvalds <torvalds@transmeta.com>,
	dhowells@redhat.com, Ulrich.Weigand@de.ibm.com,
	linux-kernel@vger.kernel.org
Subject: Re: Deadlock on the mm->mmap_sem
Date: Tue, 18 Sep 2001 09:55:49 +0200	[thread overview]
Message-ID: <20010918095549.T698@athlon.random> (raw)
In-Reply-To: <001701c13fc2$cda19a90$010411ac@local> <200109172339.f8HNd5W13244@penguin.transmeta.com> <20010918020139.B698@athlon.random> <000901c14014$494f9380$010411ac@local>
In-Reply-To: <000901c14014$494f9380$010411ac@local>; from manfred@colorfullife.com on Tue, Sep 18, 2001 at 09:31:40AM +0200

On Tue, Sep 18, 2001 at 09:31:40AM +0200, Manfred Spraul wrote:
> 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.

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.

> > 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.

Yes.

> IMHO modifying proc_pid_read_maps() is far simpler - I'm not aware of
> another recursive mmap_sem user.

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).

Andrea

  reply	other threads:[~2001-09-18  7:55 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-17 21:50 Deadlock on the mm->mmap_sem Manfred Spraul
2001-09-17 23:39 ` Linus Torvalds
     [not found] ` <200109172339.f8HNd5W13244@penguin.transmeta.com>
2001-09-18  0:01   ` Andrea Arcangeli
2001-09-18  7:31     ` Manfred Spraul
2001-09-18  7:55       ` Andrea Arcangeli [this message]
2001-09-18  8:18         ` David Howells
2001-09-18  9:32         ` David Howells
2001-09-18  9:37         ` Manfred Spraul
2001-09-18  9:49         ` Arjan van de Ven
2001-09-18 12:53         ` Manfred Spraul
2001-09-18 14:13           ` David Howells
2001-09-18 14:49             ` Alan Cox
2001-09-18 15:26               ` David Howells
2001-09-18 15:46                 ` Alan Cox
2001-09-18 15:11             ` David Howells
2001-09-18 16:49             ` Linus Torvalds
2001-09-19  9:51               ` David Howells
2001-09-19 12:49                 ` Andrea Arcangeli
2001-09-19 14:08               ` Manfred Spraul
2001-09-19 14:51               ` David Howells
2001-09-19 15:18                 ` Manfred Spraul
2001-09-19 14:53               ` David Howells
2001-09-19 18:03                 ` Andrea Arcangeli
2001-09-19 18:16                   ` Benjamin LaHaise
2001-09-19 18:27                     ` David Howells
2001-09-19 18:48                       ` Andrea Arcangeli
2001-09-19 18:45                     ` Andrea Arcangeli
2001-09-19 21:14                       ` Benjamin LaHaise
2001-09-19 22:07                         ` Andrea Arcangeli
2001-09-19 18:19                   ` Manfred Spraul
2001-09-20  2:07                     ` Andrea Arcangeli
2001-09-20  4:37                       ` Andrea Arcangeli
2001-09-20  7:05                       ` David Howells
2001-09-20  7:19                         ` Andrea Arcangeli
2001-09-20  8:01                           ` David Howells
2001-09-20  8:09                             ` Andrea Arcangeli
2001-09-19 18:26                   ` David Howells
2001-09-19 18:47                     ` Andrea Arcangeli
2001-09-19 23:25                       ` David Howells
2001-09-19 23:34                         ` Andrea Arcangeli
2001-09-19 23:46                           ` Andrea Arcangeli
2001-09-19 23:24                 ` [PATCH] attempt #2 (Re: Deadlock on the mm->mmap_sem) David Howells
2001-09-19 14:58               ` Deadlock on the mm->mmap_sem David Howells
     [not found] <masp0008@stud.uni-sb.de>
2001-09-20 10:57 ` Studierende der Universitaet des Saarlandes
2001-09-20 12:40   ` David Howells
2001-09-20 18:24   ` Andrea Arcangeli
2001-09-20 21:43     ` Manfred Spraul
2001-09-22 21:06     ` Manfred Spraul
  -- strict thread matches above, loose matches on Subject: below --
2001-09-18 13:22 Ulrich Weigand
2001-09-17 20:57 Ulrich Weigand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010918095549.T698@athlon.random \
    --to=andrea@suse.de \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=dhowells@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=torvalds@transmeta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox