From: "Stephen C. Tweedie" <sct@redhat.com>
To: Ingo Molnar <mingo@redhat.com>, Linus Torvalds <torvalds@transmeta.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.rutgers.edu,
Stephen Tweedie <sct@redhat.com>
Subject: set_pte() is no longer atomic with PAE36.
Date: Thu, 2 Dec 1999 14:27:47 GMT [thread overview]
Message-ID: <199912021427.OAA03199@dukat.scot.redhat.com> (raw)
Hi,
Ingo, do we not have a bit of a problem with set_pte() on PAE36-enabled
builds now?
#define set_pte(pteptr, pteval) ((*(pteptr)) = (pteval))
would seem to be a problem: the 64-bit write is not atomic. When
setting an unused pte, we want the word containing the page present bit
to be the last word written. When clearing a pte, though, we need the
page present bit to be cleared before we invalidate the high order word,
otherwise we're in trouble if another cpu populates its tlb whilte the
pte is in an inconsistent (but valid, to the cpu) state.
Modifying an existing pte (eg. for COW) is probably even harder: do we
need to clear the page-present bit while we modify the high word?
Simply setting the dirty or accessed bits should pose no such problem,
but relocating a page looks as if it could bite here.
Basically, as long as we can assume that another cpu will only ever see
a pte with the page-present bit clear or a completely valid pte, all
should be fine. Or have I missed something fundamental?
--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
next reply other threads:[~1999-12-02 14:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-12-02 14:27 Stephen C. Tweedie [this message]
1999-12-02 14:42 ` Alan Cox
1999-12-02 14:50 ` Ingo Molnar
1999-12-02 15:54 ` Ingo Molnar
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=199912021427.OAA03199@dukat.scot.redhat.com \
--to=sct@redhat.com \
--cc=linux-kernel@vger.rutgers.edu \
--cc=linux-mm@kvack.org \
--cc=mingo@redhat.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