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: Thu, 07 Apr 2005 21:15:20 +1000 [thread overview]
Message-ID: <1112872520.9517.282.camel@gaston> (raw)
In-Reply-To: <c689550a30a3129f8576f78eaa6f7af4@freescale.com>
> Ben, I agree with you about having the flags in a single word so we can
> lock them properly. 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,
> pte_t *ptep)
> {
> return __pte(pte_update(ptep, ~_PAGE_HASHPTE, 0));
> }
>
> It appears that we should be returning the pte that was passed in,
> before its modified? (seems a little silly to me, why bother, the
> caller could do this
No, we should return the PTE that was there before the change
atomically. It can't be done by the caller as if the caller was just
reading the PTE, there would be a race where the PTE could still change
between what you read and what you update. It has to be an atomic
operation.
> -- i've posted to lkml on the issue?). Anyways,
> since pte_update only returns the lower 32-bits the wrong thing
> happens. 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,
> pte_t *ptep)
> {
> pte_t tmp = *ptep;
> pte_update(ptep, ~_PAGE_HASHPTE, 0);
> return tmp;
> }
>
> If we are ok with this I'll send a patch upstream for it. I'd like to
> still discuss how to make this all proper long term. Currently,
> ptep_get_and_clear was the only user of pte_update that used the return
> value for anything but flags. One change would be for it to return
> just the flags portion of the pte it was given. Another would be for
> us to implement a proper 64-bit pte version of pte_update.
>
> - kumar
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
Benjamin Herrenschmidt <benh@kernel.crashing.org>
prev parent reply other threads:[~2005-04-07 11:15 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
2005-04-07 11:15 ` Benjamin Herrenschmidt [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=1112872520.9517.282.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=kumar.gala@freescale.com \
--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 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).