All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 1/3 v3] powerpc/32: Always order writes to halves of 64-bit PTEs
Date: Tue, 18 Aug 2009 14:24:42 +1000	[thread overview]
Message-ID: <1250569482.19007.23.camel@pasglop> (raw)
In-Reply-To: <19081.57584.173693.798535@cargo.ozlabs.ibm.com>

On Tue, 2009-08-18 at 09:00 +1000, Paul Mackerras wrote:
> On 32-bit systems with 64-bit PTEs, the PTEs have to be written in two
> 32-bit halves.  On SMP we write the higher-order half and then the
> lower-order half, with a write barrier between the two halves, but on
> UP there was no particular ordering of the writes to the two halves.
> 
> This extends the ordering that we already do on SMP to the UP case as
> well.  The reason is that with the perf_counter subsystem potentially
> accessing user memory at interrupt time to get stack traces, we have
> to be careful not to create an incorrect but apparently valid PTE even
> on UP.
> 
> Signed-off-by: Paul Mackerras <paulus@samba.org>

Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
> ---
>  arch/powerpc/include/asm/pgtable.h |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h
> index eb17da7..2a5da06 100644
> --- a/arch/powerpc/include/asm/pgtable.h
> +++ b/arch/powerpc/include/asm/pgtable.h
> @@ -104,8 +104,8 @@ static inline void __set_pte_at(struct mm_struct *mm, unsigned long addr,
>  	else
>  		pte_update(ptep, ~_PAGE_HASHPTE, pte_val(pte));
>  
> -#elif defined(CONFIG_PPC32) && defined(CONFIG_PTE_64BIT) && defined(CONFIG_SMP)
> -	/* Second case is 32-bit with 64-bit PTE in SMP mode. In this case, we
> +#elif defined(CONFIG_PPC32) && defined(CONFIG_PTE_64BIT)
> +	/* Second case is 32-bit with 64-bit PTE.  In this case, we
>  	 * can just store as long as we do the two halves in the right order
>  	 * with a barrier in between. This is possible because we take care,
>  	 * in the hash code, to pre-invalidate if the PTE was already hashed,
> @@ -140,7 +140,7 @@ static inline void __set_pte_at(struct mm_struct *mm, unsigned long addr,
>  
>  #else
>  	/* Anything else just stores the PTE normally. That covers all 64-bit
> -	 * cases, and 32-bit non-hash with 64-bit PTEs in UP mode
> +	 * cases, and 32-bit non-hash with 32-bit PTEs.
>  	 */
>  	*ptep = pte;
>  #endif

  parent reply	other threads:[~2009-08-18  4:24 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-17 23:00 [PATCH 1/3 v3] powerpc/32: Always order writes to halves of 64-bit PTEs Paul Mackerras
2009-08-17 23:00 ` [PATCH 2/3 v3] powerpc: Allow perf_counters to access user memory at interrupt time Paul Mackerras
2009-08-18  4:24   ` Benjamin Herrenschmidt
2009-08-17 23:01 ` [PATCH 3/3 v3] perf_counter: powerpc: Add callchain support Paul Mackerras
2009-08-18  4:23   ` Benjamin Herrenschmidt
2009-08-18  0:00 ` [PATCH 1/3 v3] powerpc/32: Always order writes to halves of 64-bit PTEs Kumar Gala
2009-08-18  0:14   ` Paul Mackerras
2009-08-18  4:24 ` Benjamin Herrenschmidt [this message]
2009-08-19 23:16   ` NAND ECC Error with wrong SMC ording bug Feng Kan
2009-08-19 23:16     ` [U-Boot] " Feng Kan
2009-08-20  4:38     ` Sean MacLennan
2009-08-20  4:38       ` [U-Boot] " Sean MacLennan
2009-08-20  5:01       ` Stefan Roese
2009-08-20  5:01         ` Stefan Roese
2009-08-20 19:36         ` Sean MacLennan
2009-08-20 19:36           ` Sean MacLennan
2009-08-20 22:56           ` Victor Gallardo
2009-08-20 22:56             ` Victor Gallardo
2009-08-20 22:56             ` Victor Gallardo
2009-08-21  5:17           ` vimal singh
2009-08-21  5:17             ` vimal singh
2009-08-21  5:17             ` vimal singh
2009-08-21  6:26             ` Sean MacLennan
2009-08-21  6:26               ` Sean MacLennan
2009-08-21  6:27             ` Stefan Roese
2009-08-21  6:27               ` Stefan Roese
2009-08-21  6:30             ` Victor Gallardo
2009-08-21  6:30               ` Victor Gallardo
2009-08-21  6:30               ` Victor Gallardo
2009-08-20 23:42         ` Feng Kan
2009-08-20 23:42           ` Feng Kan
2009-08-21  7:59           ` Stefan Roese
2009-08-21  7:59             ` Stefan Roese

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=1250569482.19007.23.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=linuxppc-dev@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.