From: Linus Torvalds <torvalds@transmeta.com>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: ganesh.sittampalam@magd.ox.ac.uk,
Virtual Memory problem report list
<linux-kernel@vger.rutgers.edu>,
mingo@valerie.inf.elte.hu, Bill Hawes <whawes@star.net>,
Alan Cox <number6@the-village.bc.nu>,
"David S. Miller" <davem@dm.cobaltmicro.com>
Subject: Re: Progress! was: Re: Yet more VM writable swap-cached pages
Date: Thu, 9 Jul 1998 17:54:21 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.3.96.980709174951.431E-100000@penguin.transmeta.com> (raw)
In-Reply-To: <199807100042.BAA07833@dax.dcs.ed.ac.uk>
On Fri, 10 Jul 1998, Stephen C. Tweedie wrote:
> with no rwe currently enabled. Page flags are normal for a resident
> swap-cached anonymous page with no IO in flight. The page count, 2, is
> also normal for a cached anonymous page. The pte, 6a8042, is not normal
> at all. It is marked non-present (the lowest bit is clear) but
> _PAGE_PROTNONE. That changes everything.
Cool. This does indeed explain it.
The _PAGE_PROTNONE was a clever way to get the correct unreadability on an
x86, but I did indeed miss the fact that now a page can be marked
"present" as far as the Linux memory management is concerned, yet not be
writable by looking at _PAGE_RW.
Your suggestion not only should fix this, but is also the RightThing(tm)
to do.
It also explains why so few people saw this - PROT_NONE is not something
that is normally used.
> What are
> the implications for other architectures which organise their ptes
> differently?
Other architectures may have the same bug, but it's actually fairly
unlikely. Most other architectures tend to have a nicer way to do
PROT_NONE anyway, and the x86 thing is a hack (but a very nice hack,
because it leaves the mm layer completely unaware of the fact that the x86
page tables are fairly deficient in this area).
So it's not a conceptual problem, it might just be something that needs to
be looked at. Certainly the alpha does not have this problem.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
next prev parent reply other threads:[~1998-07-09 23:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.3.95.980709184611.6873C-100000@fishy>
1998-07-10 0:42 ` Progress! was: Re: Yet more VM writable swap-cached pages Stephen C. Tweedie
1998-07-10 0:54 ` Linus Torvalds [this message]
1998-07-20 11:16 ` Richard Henderson
1998-07-20 17:01 ` Linus Torvalds
[not found] ` <35A57732.A7B5DFF@star.net>
1998-07-10 13:34 ` Stephen C. Tweedie
[not found] <Pine.LNX.3.95.980710021356.10100A-100000@fishy>
1998-07-10 1:26 ` Linus Torvalds
1998-07-10 2:18 ` Bill Hawes
1998-07-10 2:18 ` Linus Torvalds
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=Pine.LNX.3.96.980709174951.431E-100000@penguin.transmeta.com \
--to=torvalds@transmeta.com \
--cc=davem@dm.cobaltmicro.com \
--cc=ganesh.sittampalam@magd.ox.ac.uk \
--cc=linux-kernel@vger.rutgers.edu \
--cc=mingo@valerie.inf.elte.hu \
--cc=number6@the-village.bc.nu \
--cc=sct@redhat.com \
--cc=whawes@star.net \
/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;
as well as URLs for NNTP newsgroup(s).