From: Benjamin Herrenschmidt <benh@kernel•crashing.org>
To: Kumar Gala <kumar.gala@freescale•com>
Cc: linuxppc-dev list <linuxppc-dev@ozlabs•org>,
Paul Mackerras <paulus@samba•org>,
linux-ppc-embedded list <linuxppc-embedded@ozlabs•org>
Subject: Re: pte_update and 64-bit PTEs on PPC32?
Date: Wed, 06 Apr 2005 16:53:38 +1000 [thread overview]
Message-ID: <1112770418.9567.137.camel@gaston> (raw)
In-Reply-To: <93f533baba2b2f73ac9ec46b5401747e@freescale.com>
On Wed, 2005-04-06 at 01:51 -0500, Kumar Gala wrote:
> Paul,
>
> I've tracked down a bug I've been having to the fact that pte_update
> assumes a pte is a unsigned long. I need to look into what the exact
> implications this has. I was wondering what the thoughts were with
> respect to how this is suppose to work properly on 440 with its 64-bit
> pte? I'm looking at a 64-bit pte for some Freescale book-e parts as we
> move to 36-bit physical address support.
>
> The problem I found was ptep_get_and_clear() would return back only a
> 32-bit value and thus we loose any information in the upper 32-bits. I
> found the call in sys_mprotect ... -> change_pte_range ->
> ptep_get_and_clear()
>
> Will provide some update on this tomorrow.
It's quite important for the flags to all be together in a single 32
bits entity so that atomic operations can be done on them. The RPN
should be able to extend beyond the initial 32 bits provided we are
careful about the way we manipulate the PTEs. When setting a PTE, we
should always first set the "other" part, then the PTE present bit last
or a CPU would possibly get a stale PTE. The problem with that scheme is
that I can see possible races on dual page faults trying to fill in the
same PTE if we drop the page table lock (christoph lameter stuff) but it
should work for us now.
Ben.
next prev parent reply other threads:[~2005-04-06 6:53 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-06 6:51 pte_update and 64-bit PTEs on PPC32? Kumar Gala
2005-04-06 6:53 ` Benjamin Herrenschmidt [this message]
2005-04-06 16:44 ` Kumar Gala
2005-04-06 17:20 ` Chris Friesen
2005-04-06 17:58 ` Kumar Gala
2005-04-06 21:33 ` Kumar Gala
2005-04-08 8:26 ` Gabriel Paubert
2005-04-08 14:08 ` Kumar Gala
2005-04-08 18:44 ` Gabriel Paubert
2005-04-08 19:01 ` Kumar Gala
2005-04-08 21:04 ` Gabriel Paubert
2005-04-08 21:31 ` Dan Malek
2005-04-08 21:44 ` Gabriel Paubert
2005-04-08 23:32 ` Kumar Gala
2005-04-09 0:32 ` Paul Mackerras
2005-04-06 22:22 ` Benjamin Herrenschmidt
2005-04-06 22:27 ` Kumar Gala
2005-04-07 11:15 ` Benjamin Herrenschmidt
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=1112770418.9567.137.camel@gaston \
--to=benh@kernel$(echo .)crashing.org \
--cc=kumar.gala@freescale$(echo .)com \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=linuxppc-embedded@ozlabs$(echo .)org \
--cc=paulus@samba$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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