From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 3/5] powerpc/mm: Fix bugs in huge page hashing
Date: Fri, 23 Jul 2010 13:03:17 +1000 [thread overview]
Message-ID: <1279854197.1970.60.camel@pasglop> (raw)
In-Reply-To: <1279845704-14848-3-git-send-email-benh@kernel.crashing.org>
On Fri, 2010-07-23 at 10:41 +1000, Benjamin Herrenschmidt wrote:
> There's a couple of nasty bugs lurking in our huge page hashing code.
>
> First, we don't check the access permission atomically with setting
> the _PAGE_BUSY bit, which means that the PTE value we end up using
> for the hashing might be different than the one we have checked
> the access permissions for.
>
> We've seen cases where that leads us to try to use an invalidated
> PTE for hashing, causing all sort of "interesting" issues.
>
> Then, we also failed to set _PAGE_DIRTY on a write access.
>
> This fixes both, while also simplifying the code a bit.
The changeset lacks a comment about a change to the return value
when hitting _PAGE_BUSY and ...
> do {
> old_pte = pte_val(*ptep);
> - if (old_pte & _PAGE_BUSY)
> - goto out;
> + /* If PTE busy, retry the access */
> + if (unlikely(old_pte & _PAGE_BUSY))
> + return 0;
> + /* If PTE permissions don't match, take page fault */
> + if (unlikely(access & ~pte_val(*ptep)))
> + return 1;
old_pte will do just fine instead of reloading it
Thanks Michael !
I'll respin that one.
Cheers,
Ben.
> + /* Try to lock the PTE, add ACCESSED and DIRTY if it was
> + * a write access */
> new_pte = old_pte | _PAGE_BUSY | _PAGE_ACCESSED;
> + if (access & _PAGE_RW)
> + new_pte |= _PAGE_DIRTY;
> } while(old_pte != __cmpxchg_u64((unsigned long *)ptep,
> old_pte, new_pte));
>
> @@ -127,8 +127,7 @@ repeat:
> */
> if (unlikely(slot == -2)) {
> *ptep = __pte(old_pte);
> - err = -1;
> - goto out;
> + return -1;
> }
>
> new_pte |= (slot << 12) & (_PAGE_F_SECOND | _PAGE_F_GIX);
> @@ -138,9 +137,5 @@ repeat:
> * No need to use ldarx/stdcx here
> */
> *ptep = __pte(new_pte & ~_PAGE_BUSY);
> -
> - err = 0;
> -
> - out:
> - return err;
> + return 0;
> }
prev parent reply other threads:[~2010-07-23 3:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-23 0:41 [PATCH 1/5] powerpc/mm: Handle hypervisor pte insert failure in __hash_page_huge Benjamin Herrenschmidt
2010-07-23 0:41 ` [PATCH 2/5] powerpc/mm: Move around testing of _PAGE_PRESENT in hash code Benjamin Herrenschmidt
2010-07-23 0:41 ` [PATCH 3/5] powerpc/mm: Fix bugs in huge page hashing Benjamin Herrenschmidt
2010-07-23 0:41 ` [PATCH 4/5] powerpc/mm: Add some debug output when hash insertion fails Benjamin Herrenschmidt
2010-07-23 0:41 ` [PATCH 5/5] powerpc: Fix erroneous lmb->memblock conversions Benjamin Herrenschmidt
2010-07-23 3:03 ` 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=1279854197.1970.60.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.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).