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
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.