public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: David Mosberger <davidm@hpl.hp.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [Linux-ia64] mmap bug fix for IA-32 apps
Date: Mon, 03 Dec 2001 23:21:24 +0000	[thread overview]
Message-ID: <marc-linux-ia64-105590698805594@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590698805593@msgid-missing>

Hi Jun,

Caveat: there are a couple of nasty race conditions in the IA-32 mmap
emulation code.  I tried to fix some of that when I reworked the mmap
code, but the situation is still far from perfect.  The problem is
that the IA-32 emulator needs the mmap_sem, but it needs it at times
when it could cause page faults (which would cause a deadlock).  To
fix the worst race conditions, I introduced the separate
ia32_mmap_sem, but holding it of course doesn't stop other threads for
modifying the task's mappings through page faults.

At the moment, I'm afraid that 4KB pages is the only way to get fully
thread-safe IA-32 emulation.

Now, to your patch: it doesn't look safe to me.  It patches the old
page if VM_WRITE is set.  But what if MAP_SHARED was used to map that
page?  We may have just ended up modifying a file.

I think the proper solution is to fix the race conditions.  It's
probably best to get rid of ia32_mmap_sem alltogether, because it
harms scalability, too.  I don't have a good idea at the moment how to
fix the problem though.  Perhaps we could solve these issues properly
with a recursive mmap_sem.  IIRC, there was talk about that on the
kernel list at some point (was it Manfred?).

	--david


      reply	other threads:[~2001-12-03 23:21 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-03 22:38 [Linux-ia64] mmap bug fix for IA-32 apps Nakajima, Jun
2001-12-03 23:21 ` David Mosberger [this message]

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=marc-linux-ia64-105590698805594@msgid-missing \
    --to=davidm@hpl.hp.com \
    --cc=linux-ia64@vger.kernel.org \
    /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