From: Kumar Gala <kumar.gala@freescale.com>
To: "Benjamin Herrenschmidt" <benh@kernel.crashing.org>
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, 6 Apr 2005 17:27:22 -0500 [thread overview]
Message-ID: <7f8b1a7904bb3fd53304ee2ea4b6a501@freescale.com> (raw)
In-Reply-To: <1112826162.9568.175.camel@gaston>
On Apr 6, 2005, at 5:22 PM, Benjamin Herrenschmidt wrote:
> On Wed, 2005-04-06 at 11:44 -0500, Kumar Gala wrote:
>
> > Ben, I agree with you about having the flags in a single word so we=20=
> can
> > lock them properly.=A0 In the short term it appears that the issue =
I'm
> > running into is explicit with ptep_get_and_clear():
> >
> > static inline pte_t ptep_get_and_clear(struct mm_struct *mm, =
unsigned
> > long addr,
> >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 pte_t *ptep)
> > {
> >=A0=A0=A0=A0=A0=A0=A0=A0=A0 return __pte(pte_update(ptep, =
~_PAGE_HASHPTE, 0));
> > }
> >
> > It appears that we should be returning the pte that was passed in,
> > before its modified?=A0 (seems a little silly to me, why bother, =
the
> > caller could do this -- i've posted to lkml on the issue?).
>
> No, we should return the "old" PTE.
>
> >=A0=A0 Anyways,
> > since pte_update only returns the lower 32-bits the wrong thing
> > happens.=A0 The following seems to be a better implementation of
> > ptep_get_and_clear() for ppc32 which resolves my issue:
> >
> > static inline pte_t ptep_get_and_clear(struct mm_struct *mm, =
unsigned
> > long addr,
> >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 pte_t *ptep)
> > {
> >=A0=A0=A0=A0=A0=A0=A0=A0=A0 pte_t tmp =3D *ptep;
> >=A0=A0=A0=A0=A0=A0=A0=A0=A0 pte_update(ptep, ~_PAGE_HASHPTE, 0);
> >=A0=A0=A0=A0=A0=A0=A0=A0=A0 return tmp;
> > }
>
> Hrm... I would still do it differently. I would read the "rpn only"=20
> part
> non atomically and load/clear the other half atomically. Withotu =
that,
> you may miss a bit set between the load and the update (for example,
> _PAGE_HASHPTE may have been put in in between).
Ben,
I'll let you catch up with the rest of the thread, I realized most of=20
what you have here and created a new implementation of pte_update that=20=
should be doing what you are asking for.
- kumar
next prev parent reply other threads:[~2005-04-06 22:27 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
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 [this message]
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=7f8b1a7904bb3fd53304ee2ea4b6a501@freescale.com \
--to=kumar.gala@freescale.com \
--cc=benh@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=linuxppc-embedded@ozlabs.org \
--cc=paulus@samba.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 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.