From: Benjamin Herrenschmidt <benh@kernel.crashing.org> To: Eric Van Hensbergen <ericvh@gmail.com> Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, bg-linux@lists.anl-external.org Subject: Re: [PATCH 7/7] [RFC] SMP support code Date: Fri, 20 May 2011 11:05:29 +1000 [thread overview] Message-ID: <1305853529.7481.111.camel@pasglop> (raw) In-Reply-To: <1305753895-24845-7-git-send-email-ericvh@gmail.com> On Wed, 2011-05-18 at 16:24 -0500, Eric Van Hensbergen wrote: > +#ifdef CONFIG_BGP > +/* > + * The icbi instruction does not broadcast to all cpus in the ppc450 > + * processor used by Blue Gene/P. It is unlikely this problem will > + * be exhibited in other processors so this remains ifdef'ed for BGP > + * specifically. > + * > + * We deal with this by marking executable pages either writable, or > + * executable, but never both. The permissions will fault back and > + * forth if the thread is actively writing to executable sections. > + * Each time we fault to become executable we flush the dcache into > + * icache on all cpus. > + * I know that hack :-) I think I wrote it even (or a version of it, that was a long time ago) ;-) That doesn't make it pretty tho ... > > +struct bgp_fixup_parm { > + struct page *page; > + unsigned long address; > + struct vm_area_struct *vma; > +}; > + > +static void bgp_fixup_cache_tlb(void *parm) > +{ > + struct bgp_fixup_parm *p = parm; > + > + if (!PageHighMem(p->page)) > + flush_dcache_icache_page(p->page); > + local_flush_tlb_page(p->vma, p->address); > +} > + > +static void bgp_fixup_access_perms(struct vm_area_struct *vma, > + unsigned long address, > + int is_write, int is_exec) > +{ > + struct mm_struct *mm = vma->vm_mm; > + pte_t *ptep = NULL; > + pmd_t *pmdp; > + > + if (get_pteptr(mm, address, &ptep, &pmdp)) { > + spinlock_t *ptl = pte_lockptr(mm, pmdp); > + pte_t old; > + > + spin_lock(ptl); > + old = *ptep; > + if (pte_present(old)) { > + struct page *page = pte_page(old); > + > + if (is_exec) { > + struct bgp_fixup_parm param = { > + .page = page, > + .address = address, > + .vma = vma, > + }; > + pte_update(ptep, _PAGE_HWWRITE, 0); > + on_each_cpu(bgp_fixup_cache_tlb, ¶m, 1); Gotta be very careful with on_each_cpu() done within a lock. I wonder if we could fast-path & simplify that using crits, is there a way to shoot criticial IPIs to the other cores ? Might even be able in this case to do it entirely in asm in the page fault path. > + pte_update(ptep, 0, _PAGE_EXEC); > + pte_unmap_unlock(ptep, ptl); > + return; > + } > + if (is_write && > + (pte_val(old) & _PAGE_RW) && > + (pte_val(old) & _PAGE_DIRTY) && > + !(pte_val(old) & _PAGE_HWWRITE)) { > + pte_update(ptep, _PAGE_EXEC, _PAGE_HWWRITE); > + } > + } > + if (!pte_same(old, *ptep)) > + flush_tlb_page(vma, address); > + pte_unmap_unlock(ptep, ptl); > + } > +} > +#endif /* CONFIG_BGP */ > + > /* > * For 600- and 800-family processors, the error_code parameter is DSISR > * for a data fault, SRR1 for an instruction fault. For 400-family processors > @@ -333,6 +404,12 @@ good_area: > perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MIN, 1, 0, > regs, address); > } > + > +#ifdef CONFIG_BGP > + /* Fixup _PAGE_EXEC and _PAGE_HWWRITE if necessary */ > + bgp_fixup_access_perms(vma, address, is_write, is_exec); > +#endif /* CONFIG_BGP */ > + > up_read(&mm->mmap_sem); > return 0; > > diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype > index 3a3c711..b77a25f 100644 > --- a/arch/powerpc/platforms/Kconfig.cputype > +++ b/arch/powerpc/platforms/Kconfig.cputype > @@ -300,7 +300,7 @@ config PPC_PERF_CTRS > This enables the powerpc-specific perf_event back-end. > > config SMP > - depends on PPC_BOOK3S || PPC_BOOK3E || FSL_BOOKE || PPC_47x > + depends on PPC_BOOK3S || PPC_BOOK3E || FSL_BOOKE || PPC_47x || BGP > bool "Symmetric multi-processing support" > ---help--- > This enables support for systems with more than one CPU. If you have
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> To: Eric Van Hensbergen <ericvh@gmail.com> Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, bg-linux@lists.anl-external.org Subject: Re: [PATCH 7/7] [RFC] SMP support code Date: Fri, 20 May 2011 11:05:29 +1000 [thread overview] Message-ID: <1305853529.7481.111.camel@pasglop> (raw) In-Reply-To: <1305753895-24845-7-git-send-email-ericvh@gmail.com> On Wed, 2011-05-18 at 16:24 -0500, Eric Van Hensbergen wrote: > +#ifdef CONFIG_BGP > +/* > + * The icbi instruction does not broadcast to all cpus in the ppc450 > + * processor used by Blue Gene/P. It is unlikely this problem will > + * be exhibited in other processors so this remains ifdef'ed for BGP > + * specifically. > + * > + * We deal with this by marking executable pages either writable, or > + * executable, but never both. The permissions will fault back and > + * forth if the thread is actively writing to executable sections. > + * Each time we fault to become executable we flush the dcache into > + * icache on all cpus. > + * I know that hack :-) I think I wrote it even (or a version of it, that was a long time ago) ;-) That doesn't make it pretty tho ... > > +struct bgp_fixup_parm { > + struct page *page; > + unsigned long address; > + struct vm_area_struct *vma; > +}; > + > +static void bgp_fixup_cache_tlb(void *parm) > +{ > + struct bgp_fixup_parm *p = parm; > + > + if (!PageHighMem(p->page)) > + flush_dcache_icache_page(p->page); > + local_flush_tlb_page(p->vma, p->address); > +} > + > +static void bgp_fixup_access_perms(struct vm_area_struct *vma, > + unsigned long address, > + int is_write, int is_exec) > +{ > + struct mm_struct *mm = vma->vm_mm; > + pte_t *ptep = NULL; > + pmd_t *pmdp; > + > + if (get_pteptr(mm, address, &ptep, &pmdp)) { > + spinlock_t *ptl = pte_lockptr(mm, pmdp); > + pte_t old; > + > + spin_lock(ptl); > + old = *ptep; > + if (pte_present(old)) { > + struct page *page = pte_page(old); > + > + if (is_exec) { > + struct bgp_fixup_parm param = { > + .page = page, > + .address = address, > + .vma = vma, > + }; > + pte_update(ptep, _PAGE_HWWRITE, 0); > + on_each_cpu(bgp_fixup_cache_tlb, ¶m, 1); Gotta be very careful with on_each_cpu() done within a lock. I wonder if we could fast-path & simplify that using crits, is there a way to shoot criticial IPIs to the other cores ? Might even be able in this case to do it entirely in asm in the page fault path. > + pte_update(ptep, 0, _PAGE_EXEC); > + pte_unmap_unlock(ptep, ptl); > + return; > + } > + if (is_write && > + (pte_val(old) & _PAGE_RW) && > + (pte_val(old) & _PAGE_DIRTY) && > + !(pte_val(old) & _PAGE_HWWRITE)) { > + pte_update(ptep, _PAGE_EXEC, _PAGE_HWWRITE); > + } > + } > + if (!pte_same(old, *ptep)) > + flush_tlb_page(vma, address); > + pte_unmap_unlock(ptep, ptl); > + } > +} > +#endif /* CONFIG_BGP */ > + > /* > * For 600- and 800-family processors, the error_code parameter is DSISR > * for a data fault, SRR1 for an instruction fault. For 400-family processors > @@ -333,6 +404,12 @@ good_area: > perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS_MIN, 1, 0, > regs, address); > } > + > +#ifdef CONFIG_BGP > + /* Fixup _PAGE_EXEC and _PAGE_HWWRITE if necessary */ > + bgp_fixup_access_perms(vma, address, is_write, is_exec); > +#endif /* CONFIG_BGP */ > + > up_read(&mm->mmap_sem); > return 0; > > diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype > index 3a3c711..b77a25f 100644 > --- a/arch/powerpc/platforms/Kconfig.cputype > +++ b/arch/powerpc/platforms/Kconfig.cputype > @@ -300,7 +300,7 @@ config PPC_PERF_CTRS > This enables the powerpc-specific perf_event back-end. > > config SMP > - depends on PPC_BOOK3S || PPC_BOOK3E || FSL_BOOKE || PPC_47x > + depends on PPC_BOOK3S || PPC_BOOK3E || FSL_BOOKE || PPC_47x || BGP > bool "Symmetric multi-processing support" > ---help--- > This enables support for systems with more than one CPU. If you have
next prev parent reply other threads:[~2011-05-20 1:05 UTC|newest] Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-05-18 21:24 [PATCH 1/7] [RFC] Mainline BG/P platform support Eric Van Hensbergen 2011-05-18 21:24 ` Eric Van Hensbergen 2011-05-18 21:24 ` [PATCH 2/7] [RFC] add bluegene entry to cputable Eric Van Hensbergen 2011-05-18 21:24 ` Eric Van Hensbergen 2011-05-20 0:35 ` Benjamin Herrenschmidt 2011-05-20 0:35 ` Benjamin Herrenschmidt 2011-05-20 1:08 ` Eric Van Hensbergen 2011-05-20 1:08 ` Eric Van Hensbergen 2011-05-20 1:50 ` Benjamin Herrenschmidt 2011-05-20 1:50 ` Benjamin Herrenschmidt 2011-05-18 21:24 ` [PATCH 3/7] [RFC] add support for BlueGene/P FPU Eric Van Hensbergen 2011-05-18 21:24 ` Eric Van Hensbergen 2011-05-19 5:58 ` Michael Neuling 2011-05-19 5:58 ` Michael Neuling 2011-05-19 13:53 ` Eric Van Hensbergen 2011-05-19 13:53 ` Eric Van Hensbergen 2011-05-19 15:22 ` [bg-linux] " Kazutomo Yoshii 2011-05-19 21:36 ` Michael Neuling 2011-05-19 21:36 ` Michael Neuling 2011-05-19 21:55 ` Eric Van Hensbergen 2011-05-19 21:55 ` Eric Van Hensbergen 2011-05-19 23:16 ` Michael Neuling 2011-05-19 23:16 ` Michael Neuling 2011-05-20 0:30 ` Eric Van Hensbergen 2011-05-20 0:30 ` Eric Van Hensbergen 2011-05-20 0:43 ` Michael Neuling 2011-05-20 0:43 ` Michael Neuling 2011-05-20 0:53 ` Benjamin Herrenschmidt 2011-05-20 0:52 ` Benjamin Herrenschmidt 2011-05-20 0:52 ` Benjamin Herrenschmidt 2011-05-19 21:41 ` [PATCH 3/7] [RFC][V2] add support for BlueGene/P Double FPU Eric Van Hensbergen 2011-05-19 21:41 ` Eric Van Hensbergen 2011-05-18 21:24 ` [PATCH 4/7] [RFC] enable L1_WRITETHROUGH mode for BG/P Eric Van Hensbergen 2011-05-18 21:24 ` Eric Van Hensbergen 2011-05-19 10:43 ` Josh Boyer 2011-05-19 10:43 ` Josh Boyer 2011-05-19 12:53 ` Eric Van Hensbergen 2011-05-19 12:53 ` Eric Van Hensbergen 2011-05-19 21:42 ` [PATCH 4/7] [RFC][V2] enable BGP_L1_WRITETHROUGH " Eric Van Hensbergen 2011-05-19 21:42 ` Eric Van Hensbergen 2011-05-20 1:01 ` [PATCH 4/7] [RFC] enable L1_WRITETHROUGH " Benjamin Herrenschmidt 2011-05-20 1:01 ` Benjamin Herrenschmidt 2011-05-18 21:24 ` [PATCH 5/7] [RFC] force 32-byte aligned kmallocs Eric Van Hensbergen 2011-05-18 21:24 ` Eric Van Hensbergen 2011-05-20 0:36 ` Benjamin Herrenschmidt 2011-05-20 0:36 ` Benjamin Herrenschmidt 2011-05-20 0:47 ` Eric Van Hensbergen 2011-05-20 0:47 ` Eric Van Hensbergen 2011-05-20 1:50 ` Benjamin Herrenschmidt 2011-05-20 1:50 ` Benjamin Herrenschmidt 2011-05-20 1:32 ` [bg-linux] " Kazutomo Yoshii 2011-05-20 2:08 ` Benjamin Herrenschmidt 2011-05-20 2:08 ` Benjamin Herrenschmidt 2011-05-20 2:13 ` Benjamin Herrenschmidt 2011-05-20 2:13 ` Benjamin Herrenschmidt 2011-05-20 3:02 ` Kazutomo Yoshii 2011-05-20 3:13 ` Benjamin Herrenschmidt 2011-05-18 21:24 ` [PATCH 6/7] [RFC] enable early TLBs for BG/P Eric Van Hensbergen 2011-05-18 21:24 ` Eric Van Hensbergen 2011-05-20 0:39 ` Benjamin Herrenschmidt 2011-05-20 0:39 ` Benjamin Herrenschmidt 2011-05-20 1:21 ` Eric Van Hensbergen 2011-05-20 1:21 ` Eric Van Hensbergen 2011-05-20 1:54 ` Benjamin Herrenschmidt 2011-05-20 1:54 ` Benjamin Herrenschmidt 2011-05-20 3:38 ` [bg-linux] " Kazutomo Yoshii 2011-05-20 3:38 ` Kazutomo Yoshii 2011-05-20 3:52 ` Benjamin Herrenschmidt 2011-05-20 3:52 ` Benjamin Herrenschmidt 2011-05-20 13:01 ` Eric Van Hensbergen 2011-05-20 22:20 ` Benjamin Herrenschmidt 2011-05-18 21:24 ` [PATCH 7/7] [RFC] SMP support code Eric Van Hensbergen 2011-05-18 21:24 ` Eric Van Hensbergen 2011-05-20 1:05 ` Benjamin Herrenschmidt [this message] 2011-05-20 1:05 ` Benjamin Herrenschmidt 2011-05-19 11:01 ` [PATCH 1/7] [RFC] Mainline BG/P platform support Josh Boyer 2011-05-19 11:01 ` Josh Boyer 2011-05-19 12:35 ` Eric Van Hensbergen 2011-05-19 12:35 ` Eric Van Hensbergen
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=1305853529.7481.111.camel@pasglop \ --to=benh@kernel.crashing.org \ --cc=bg-linux@lists.anl-external.org \ --cc=ericvh@gmail.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linuxppc-dev@lists.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: linkBe 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.