* Re: [PATCH 3/3] perf, x86, lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL
From: Peter Zijlstra @ 2013-05-17 11:39 UTC (permalink / raw)
To: Michael Neuling
Cc: ak@linux.intel.com, LKML, Stephane Eranian, Linux PPC dev,
Ingo Molnar
In-Reply-To: <29969.1368790328@ale.ozlabs.ibm.com>
On Fri, May 17, 2013 at 09:32:08PM +1000, Michael Neuling wrote:
> Peter Zijlstra <peterz@infradead.org> wrote:
> > Wouldn't it be mostly conditional branches that are the primary control flow
> > and can get predicted wrong? I mean, I'm sure someone will miss-predict an
> > unconditional branch but its not like we care about people with such
> > afflictions do we?
>
> You could mispredict the target address of a computed goto. You'd know
> it was taken but not know target address until later in the pipeline.
Oh right, computed targets could indeed be mis predicted. I was more thinking
about jumps with immediate values.
> On this, the POWER8 branch history buffer tells us two things about the
> prediction status.
> 1) if the branch was predicted taken/not taken correctly
> 2) if the target address was predicted correctly or not (for computed
> gotos only)
> So we'd actually like more prediction bits too :-D
So if I understand this right, 1) maps to the predicted flags we have; 2)
would be new stuff?
We don't really have anything like that on x86, but I suppose if you make the
thing optional and present a 'useful' use-case implemented in userspace code
we could take it :-)
> > Anyway, since PPC people thought it worth baking into hardware,
> > presumably they have a compelling use case. Mikey could you see if you
> > can retrieve that from someone in the know? It might be interesting.
>
> I don't think we can mispredict a non-conditional non-computed but I'll
> have to check with the HW folks.
I was mostly wondering about the use-case for the conditional filter. Stephane
didn't think it useful, clearly your hardware guys thought different :-)
^ permalink raw reply
* Re: [PATCH 3/3] perf, x86, lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL
From: Michael Neuling @ 2013-05-17 11:32 UTC (permalink / raw)
To: Peter Zijlstra
Cc: ak@linux.intel.com, LKML, Stephane Eranian, Linux PPC dev,
Ingo Molnar
In-Reply-To: <20130517111232.GE5162@dyad.programming.kicks-ass.net>
Peter Zijlstra <peterz@infradead.org> wrote:
> On Thu, May 16, 2013 at 05:36:11PM +0200, Stephane Eranian wrote:
> > On Thu, May 16, 2013 at 1:16 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> > > On Thu, May 16, 2013 at 08:15:17PM +1000, Michael Neuling wrote:
> > >> Peter,
> > >>
> > >> BTW PowerPC also has the ability to filter on conditional branches. Any
> > >> chance we could add something like the follow to perf also?
> > >>
> > >
> > > I don't see an immediate problem with that except that we on x86 need to
> > > implement that in the software filter. Stephane do you see any
> > > fundamental issue with that?
> > >
> > On X86, the LBR cannot filter on conditional in HW. Thus as Peter said, it would
> > have to be done in SW. I did not add that because I think those branches are
> > not necessarily useful for tools.
>
> Wouldn't it be mostly conditional branches that are the primary control flow
> and can get predicted wrong? I mean, I'm sure someone will miss-predict an
> unconditional branch but its not like we care about people with such
> afflictions do we?
You could mispredict the target address of a computed goto. You'd know
it was taken but not know target address until later in the pipeline.
On this, the POWER8 branch history buffer tells us two things about the
prediction status.
1) if the branch was predicted taken/not taken correctly
2) if the target address was predicted correctly or not (for computed
gotos only)
So we'd actually like more prediction bits too :-D
> Anyway, since PPC people thought it worth baking into hardware,
> presumably they have a compelling use case. Mikey could you see if you
> can retrieve that from someone in the know? It might be interesting.
I don't think we can mispredict a non-conditional non-computed but I'll
have to check with the HW folks.
Mikey
>
> Also, it looks like its trivial to add to x86, you seem to have already done
> all the hard work by having X86_BR_JCC.
>
> The only missing piece would be:
>
> --- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
> +++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
> @@ -337,6 +337,10 @@ static int intel_pmu_setup_sw_lbr_filter
>
> if (br_type & PERF_SAMPLE_BRANCH_IND_CALL)
> mask |= X86_BR_IND_CALL;
> +
> + if (br_type & PERF_SAMPLE_BRANCH_CONDITIONAL)
> + mask |= X86_BR_JCC;
> +
> /*
> * stash actual user request into reg, it may
> * be used by fixup code for some CPU
>
^ permalink raw reply
* Re: [PATCH 3/3] perf, x86, lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL
From: Peter Zijlstra @ 2013-05-17 11:12 UTC (permalink / raw)
To: Stephane Eranian
Cc: Michael Neuling, ak@linux.intel.com, LKML, Linux PPC dev,
Ingo Molnar
In-Reply-To: <CABPqkBSCXJN7gLK_e_Q3YVVVFVGS78fo4j2z0+MmriqoXszH+w@mail.gmail.com>
On Thu, May 16, 2013 at 05:36:11PM +0200, Stephane Eranian wrote:
> On Thu, May 16, 2013 at 1:16 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Thu, May 16, 2013 at 08:15:17PM +1000, Michael Neuling wrote:
> >> Peter,
> >>
> >> BTW PowerPC also has the ability to filter on conditional branches. Any
> >> chance we could add something like the follow to perf also?
> >>
> >
> > I don't see an immediate problem with that except that we on x86 need to
> > implement that in the software filter. Stephane do you see any
> > fundamental issue with that?
> >
> On X86, the LBR cannot filter on conditional in HW. Thus as Peter said, it would
> have to be done in SW. I did not add that because I think those branches are
> not necessarily useful for tools.
Wouldn't it be mostly conditional branches that are the primary control flow
and can get predicted wrong? I mean, I'm sure someone will miss-predict an
unconditional branch but its not like we care about people with such
afflictions do we?
Anyway, since PPC people thought it worth baking into hardware, presumably they
have a compelling use case. Mikey could you see if you can retrieve that from
someone in the know? It might be interesting.
Also, it looks like its trivial to add to x86, you seem to have already done
all the hard work by having X86_BR_JCC.
The only missing piece would be:
--- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
@@ -337,6 +337,10 @@ static int intel_pmu_setup_sw_lbr_filter
if (br_type & PERF_SAMPLE_BRANCH_IND_CALL)
mask |= X86_BR_IND_CALL;
+
+ if (br_type & PERF_SAMPLE_BRANCH_CONDITIONAL)
+ mask |= X86_BR_JCC;
+
/*
* stash actual user request into reg, it may
* be used by fixup code for some CPU
^ permalink raw reply
* Re: [PATCH v2] can: flexcan: remove HAVE_CAN_FLEXCAN Kconfig symbol
From: Shawn Guo @ 2013-05-17 9:09 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Arnd Bergmann, Sascha Hauer, U Bhaskar-B22300, linux-kernel,
linux-can, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1368781157-4646-1-git-send-email-mkl@pengutronix.de>
On Fri, May 17, 2013 at 10:59:17AM +0200, Marc Kleine-Budde wrote:
> This patch removes the Kconfig symbol HAVE_CAN_FLEXCAN from arch/{arm,powerpc}
> and allowing compilation unconditionally on all arm and powerpc platforms.
>
> This brings a bigger compile time coverage and removes the following dependency
> warning found by Arnd Bergmann:
>
> warning: (SOC_IMX28 && SOC_IMX25 && SOC_IMX35 && IMX_HAVE_PLATFORM_FLEXCAN &&
> SOC_IMX53 && SOC_IMX6Q) selects HAVE_CAN_FLEXCAN
> which has unmet direct dependencies (NET && CAN && CAN_DEV)
>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Kumar Gala <galak@kernel.crashing.org>
> Cc: U Bhaskar-B22300 <B22300@freescale.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
^ permalink raw reply
* [PATCH v2] can: flexcan: remove HAVE_CAN_FLEXCAN Kconfig symbol
From: Marc Kleine-Budde @ 2013-05-17 8:59 UTC (permalink / raw)
To: linux-kernel
Cc: Arnd Bergmann, Sascha Hauer, U Bhaskar-B22300, linux-can,
Marc Kleine-Budde, Shawn Guo, linuxppc-dev, linux-arm-kernel
This patch removes the Kconfig symbol HAVE_CAN_FLEXCAN from arch/{arm,powerpc}
and allowing compilation unconditionally on all arm and powerpc platforms.
This brings a bigger compile time coverage and removes the following dependency
warning found by Arnd Bergmann:
warning: (SOC_IMX28 && SOC_IMX25 && SOC_IMX35 && IMX_HAVE_PLATFORM_FLEXCAN &&
SOC_IMX53 && SOC_IMX6Q) selects HAVE_CAN_FLEXCAN
which has unmet direct dependencies (NET && CAN && CAN_DEV)
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: U Bhaskar-B22300 <B22300@freescale.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
Changes since v1:
- don't remove IMX_HAVE_PLATFORM_FLEXCAN, which breaks non DT imx platforms
tnx Shawn
arch/arm/mach-imx/Kconfig | 4 ----
arch/arm/mach-imx/devices/Kconfig | 1 -
arch/arm/mach-mxs/Kconfig | 1 -
arch/powerpc/Kconfig | 1 -
drivers/net/can/Kconfig | 5 +----
5 files changed, 1 insertion(+), 11 deletions(-)
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index ba44328..af8e109 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -111,7 +111,6 @@ config SOC_IMX25
select ARCH_MXC_IOMUX_V3
select COMMON_CLK
select CPU_ARM926T
- select HAVE_CAN_FLEXCAN if CAN
select MXC_AVIC
config SOC_IMX27
@@ -137,7 +136,6 @@ config SOC_IMX35
select ARCH_MXC_IOMUX_V3
select COMMON_CLK
select CPU_V6K
- select HAVE_CAN_FLEXCAN if CAN
select HAVE_EPIT
select MXC_AVIC
select SMP_ON_UP if SMP
@@ -776,7 +774,6 @@ comment "Device tree only"
config SOC_IMX53
bool "i.MX53 support"
- select HAVE_CAN_FLEXCAN if CAN
select HAVE_IMX_SRC
select IMX_HAVE_PLATFORM_IMX2_WDT
select PINCTRL
@@ -799,7 +796,6 @@ config SOC_IMX6Q
select CPU_V7
select HAVE_ARM_SCU if SMP
select HAVE_ARM_TWD if LOCAL_TIMERS
- select HAVE_CAN_FLEXCAN if CAN
select HAVE_IMX_ANATOP
select HAVE_IMX_GPC
select HAVE_IMX_MMDC
diff --git a/arch/arm/mach-imx/devices/Kconfig b/arch/arm/mach-imx/devices/Kconfig
index 3dd2b1b..68c74fb 100644
--- a/arch/arm/mach-imx/devices/Kconfig
+++ b/arch/arm/mach-imx/devices/Kconfig
@@ -4,7 +4,6 @@ config IMX_HAVE_PLATFORM_FEC
config IMX_HAVE_PLATFORM_FLEXCAN
bool
- select HAVE_CAN_FLEXCAN if CAN
config IMX_HAVE_PLATFORM_FSL_USB2_UDC
bool
diff --git a/arch/arm/mach-mxs/Kconfig b/arch/arm/mach-mxs/Kconfig
index 4dc2fbb..ce6e7d6 100644
--- a/arch/arm/mach-mxs/Kconfig
+++ b/arch/arm/mach-mxs/Kconfig
@@ -11,7 +11,6 @@ config SOC_IMX28
select ARM_AMBA
select ARM_CPU_SUSPEND if PM
select CPU_ARM926T
- select HAVE_CAN_FLEXCAN if CAN
select HAVE_PWM
select PINCTRL_IMX28
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c33e3ad..7754c6b 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -674,7 +674,6 @@ config SBUS
config FSL_SOC
bool
- select HAVE_CAN_FLEXCAN if NET && CAN
config FSL_PCI
bool
diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
index e456b70..3c06947 100644
--- a/drivers/net/can/Kconfig
+++ b/drivers/net/can/Kconfig
@@ -102,12 +102,9 @@ config CAN_JANZ_ICAN3
This driver can also be built as a module. If so, the module will be
called janz-ican3.ko.
-config HAVE_CAN_FLEXCAN
- bool
-
config CAN_FLEXCAN
tristate "Support for Freescale FLEXCAN based chips"
- depends on HAVE_CAN_FLEXCAN
+ depends on ARM || PPC
---help---
Say Y here if you want to support for Freescale FlexCAN.
--
1.8.2.rc2
^ permalink raw reply related
* Re: [PATCH] can: flexcan: allow compilation on arm and powerpc
From: Marc Kleine-Budde @ 2013-05-17 8:51 UTC (permalink / raw)
To: Shawn Guo
Cc: Arnd Bergmann, Sascha Hauer, U Bhaskar-B22300, linux-kernel,
linux-can, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20130517020351.GE3893@S2101-09.ap.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 908 bytes --]
On 05/17/2013 04:03 AM, Shawn Guo wrote:
> Hi Marc,
>
> On Thu, May 16, 2013 at 03:42:36PM +0200, Marc Kleine-Budde wrote:
>> This patch removes the Kconfig symbols HAVE_CAN_FLEXCAN and
>> IMX_HAVE_PLATFORM_FLEXCAN from arch/{arm,powerpc} and allowing compilation on
>> all arm and powerpc platforms.
>
> I'm generally fine with the approach. But with Kconfig symbol
> IMX_HAVE_PLATFORM_FLEXCAN removed, how does the build of
> platform-flexcan.o work?
>
> arch/arm/mach-imx/devices/Makefile:obj-$(CONFIG_IMX_HAVE_PLATFORM_FLEXCAN) += platform-flexcan.o
Doh! - I've removed too much, will change.
Tnx,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: split hugepage when using subpage protection
From: Aneesh Kumar K.V @ 2013-05-17 8:36 UTC (permalink / raw)
To: benh, paulus, dwg; +Cc: linuxppc-dev
In-Reply-To: <1368778503-23230-2-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> writes:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> We find all the overlapping vma and mark them such that we don't allocate
> hugepage in that range. Also we split existing huge page so that the
> normal page hash can be invalidated and new page faulted in with new
> protection bits.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> ---
> arch/powerpc/mm/subpage-prot.c | 27 +++++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
>
> diff --git a/arch/powerpc/mm/subpage-prot.c b/arch/powerpc/mm/subpage-prot.c
> index 7c415dd..33fd329 100644
> --- a/arch/powerpc/mm/subpage-prot.c
> +++ b/arch/powerpc/mm/subpage-prot.c
> @@ -130,6 +130,14 @@ static void subpage_prot_clear(unsigned long addr, unsigned long len)
> up_write(&mm->mmap_sem);
> }
>
> +static int subpage_walk_pmd_entry(pmd_t *pmd, unsigned long addr,
> + unsigned long end, struct mm_walk *walk)
> +{
> + struct vm_area_struct *vma = walk->private;
> + split_huge_page_pmd(vma, addr, pmd);
> + return 0;
> +}
> +
> /*
> * Copy in a subpage protection map for an address range.
> * The map has 2 bits per 4k subpage, so 32 bits per 64k page.
> @@ -149,6 +157,12 @@ long sys_subpage_prot(unsigned long addr, unsigned long len, u32 __user *map)
> size_t nw;
> unsigned long next, limit;
> int err;
> + struct vm_area_struct *vma;
> +
> + struct mm_walk subpage_proto_walk = {
> + .mm = mm,
> + .pmd_entry = subpage_walk_pmd_entry,
> + };
>
> /* Check parameters */
> if ((addr & ~PAGE_MASK) || (len & ~PAGE_MASK) ||
> @@ -168,6 +182,19 @@ long sys_subpage_prot(unsigned long addr, unsigned long len, u32 __user *map)
> return -EFAULT;
>
> down_write(&mm->mmap_sem);
> +
> + /*
> + * We don't try too hard, we just mark all the vma in that range
> + * VM_NOHUGEPAGE and split them.
> + */
> + for (vma = find_vma(mm, addr);
> + (vma && vma->vm_end < (addr + len)); vma = vma->vm_next) {
should be, Missed commit -amend
(vma && vma->vm_start < (addr + len)); vma = vma->vm_next) {
> + vma->vm_flags |= VM_NOHUGEPAGE;
> + subpage_proto_walk.private = vma;
> + walk_page_range(vma->vm_start, vma->vm_end,
> + &subpage_proto_walk);
> + }
> for (limit = addr + len; addr < limit; addr = next) {
> next = pmd_addr_end(addr, limit);
> err = -ENOMEM;
-aneesh
^ permalink raw reply
* [PATCH 1/2] powerpc: use smp_rmb when looking at deposisted pgtable to store hash index
From: Aneesh Kumar K.V @ 2013-05-17 8:15 UTC (permalink / raw)
To: benh, paulus, dwg; +Cc: linuxppc-dev, Aneesh Kumar K.V
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
We need to use smb_rmb when looking at hpte slot array. Otherwise we could
reorder the hpte_slot array load bfore even we marked the pmd trans huge.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/pgtable-ppc64.h | 15 +++++++++++++++
arch/powerpc/mm/hugepage-hash64.c | 6 +-----
arch/powerpc/mm/pgtable_64.c | 6 +-----
3 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h b/arch/powerpc/include/asm/pgtable-ppc64.h
index d046289..46db094 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -10,6 +10,7 @@
#else
#include <asm/pgtable-ppc64-4k.h>
#endif
+#include <asm/barrier.h>
#define FIRST_USER_ADDRESS 0
@@ -393,6 +394,20 @@ static inline void mark_hpte_slot_valid(unsigned char *hpte_slot_array,
hpte_slot_array[index] = hidx << 4 | 0x1 << 3;
}
+static inline char *get_hpte_slot_array(pmd_t *pmdp)
+{
+ /*
+ * The hpte hindex is stored in the pgtable whose address is in the
+ * second half of the PMD
+ *
+ * Order this load with the test for pmd_trans_huge in the caller
+ */
+ smp_rmb();
+ return *(char **)(pmdp + PTRS_PER_PMD);
+
+
+}
+
extern void hpte_do_hugepage_flush(struct mm_struct *mm, unsigned long addr,
pmd_t *pmdp);
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
diff --git a/arch/powerpc/mm/hugepage-hash64.c b/arch/powerpc/mm/hugepage-hash64.c
index e430766..c3ba3d5 100644
--- a/arch/powerpc/mm/hugepage-hash64.c
+++ b/arch/powerpc/mm/hugepage-hash64.c
@@ -84,11 +84,7 @@ int __hash_page_thp(unsigned long ea, unsigned long access, unsigned long vsid,
vpn = hpt_vpn(ea, vsid, ssize);
hash = hpt_hash(vpn, shift, ssize);
- /*
- * The hpte hindex are stored in the pgtable whose address is in the
- * second half of the PMD
- */
- hpte_slot_array = *(char **)(pmdp + PTRS_PER_PMD);
+ hpte_slot_array = get_hpte_slot_array(pmdp);
valid = hpte_valid(hpte_slot_array, index);
if (valid) {
diff --git a/arch/powerpc/mm/pgtable_64.c b/arch/powerpc/mm/pgtable_64.c
index 8dd7c83..19d6734 100644
--- a/arch/powerpc/mm/pgtable_64.c
+++ b/arch/powerpc/mm/pgtable_64.c
@@ -701,11 +701,7 @@ void hpte_do_hugepage_flush(struct mm_struct *mm, unsigned long addr,
* Flush all the hptes mapping this hugepage
*/
s_addr = addr & HPAGE_PMD_MASK;
- /*
- * The hpte hindex are stored in the pgtable whose address is in the
- * second half of the PMD
- */
- hpte_slot_array = *(char **)(pmdp + PTRS_PER_PMD);
+ hpte_slot_array = get_hpte_slot_array(pmdp);
/*
* IF we try to do a HUGE PTE update after a withdraw is done.
* we will find the below NULL. This happens when we do
--
1.8.1.2
^ permalink raw reply related
* [PATCH 2/2] powerpc: split hugepage when using subpage protection
From: Aneesh Kumar K.V @ 2013-05-17 8:15 UTC (permalink / raw)
To: benh, paulus, dwg; +Cc: linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <1368778503-23230-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
We find all the overlapping vma and mark them such that we don't allocate
hugepage in that range. Also we split existing huge page so that the
normal page hash can be invalidated and new page faulted in with new
protection bits.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
arch/powerpc/mm/subpage-prot.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/powerpc/mm/subpage-prot.c b/arch/powerpc/mm/subpage-prot.c
index 7c415dd..33fd329 100644
--- a/arch/powerpc/mm/subpage-prot.c
+++ b/arch/powerpc/mm/subpage-prot.c
@@ -130,6 +130,14 @@ static void subpage_prot_clear(unsigned long addr, unsigned long len)
up_write(&mm->mmap_sem);
}
+static int subpage_walk_pmd_entry(pmd_t *pmd, unsigned long addr,
+ unsigned long end, struct mm_walk *walk)
+{
+ struct vm_area_struct *vma = walk->private;
+ split_huge_page_pmd(vma, addr, pmd);
+ return 0;
+}
+
/*
* Copy in a subpage protection map for an address range.
* The map has 2 bits per 4k subpage, so 32 bits per 64k page.
@@ -149,6 +157,12 @@ long sys_subpage_prot(unsigned long addr, unsigned long len, u32 __user *map)
size_t nw;
unsigned long next, limit;
int err;
+ struct vm_area_struct *vma;
+
+ struct mm_walk subpage_proto_walk = {
+ .mm = mm,
+ .pmd_entry = subpage_walk_pmd_entry,
+ };
/* Check parameters */
if ((addr & ~PAGE_MASK) || (len & ~PAGE_MASK) ||
@@ -168,6 +182,19 @@ long sys_subpage_prot(unsigned long addr, unsigned long len, u32 __user *map)
return -EFAULT;
down_write(&mm->mmap_sem);
+
+ /*
+ * We don't try too hard, we just mark all the vma in that range
+ * VM_NOHUGEPAGE and split them.
+ */
+ for (vma = find_vma(mm, addr);
+ (vma && vma->vm_end < (addr + len)); vma = vma->vm_next) {
+
+ vma->vm_flags |= VM_NOHUGEPAGE;
+ subpage_proto_walk.private = vma;
+ walk_page_range(vma->vm_start, vma->vm_end,
+ &subpage_proto_walk);
+ }
for (limit = addr + len; addr < limit; addr = next) {
next = pmd_addr_end(addr, limit);
err = -ENOMEM;
--
1.8.1.2
^ permalink raw reply related
* [PATCH] powerpc/pci: fix PCI-e check link issue
From: Yuanquan Chen @ 2013-05-17 7:35 UTC (permalink / raw)
To: linuxppc-dev, galak; +Cc: Yuanquan Chen, r61911
For Freescale powerpc platform, the PCI-e bus number uses the reassign mode
by default. It means the second PCI-e controller's hose->first_busno is the
first controller's last bus number adding 1. For some hotpluged device(or
controlled by FPGA), the device is linked to PCI-e slot at linux runtime.
It needs rescan for the system to add it and driver it to work. It successes
to rescan the device linked to the first PCI-e controller's slot, but fails to
rescan the device linked to the second PCI-e controller's slot. The cause is
that the bus->number is reset to 0, which isn't equal to the hose->first_busno
for the second controller checking PCI-e link. So it doesn't really check the
PCI-e link status, the link status is always no_link. The device won't be
really rescaned. Reset the bus->number to hose->first_busno in the function
fsl_pcie_check_link(), it will do the real checking PCI-e link status for the
second controller, the device will be rescaned.
Signed-off-by: Yuanquan Chen <Yuanquan.Chen@freescale.com>
---
arch/powerpc/sysdev/fsl_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 028ac1f..534597a 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -64,7 +64,7 @@ static int fsl_pcie_check_link(struct pci_controller *hose)
if (hose->indirect_type & PPC_INDIRECT_TYPE_FSL_CFG_REG_LINK) {
if (hose->ops->read == fsl_indirect_read_config) {
struct pci_bus bus;
- bus.number = 0;
+ bus.number = hose->first_busno;
bus.sysdata = hose;
bus.ops = hose->ops;
indirect_read_config(&bus, 0, PCIE_LTSSM, 4, &val);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] powerpc/pci: remove the unused variables in pci_process_bridge_OF_ranges
From: Kevin Hao @ 2013-05-17 6:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc
In-Reply-To: <1368773922-19754-1-git-send-email-haokexin@gmail.com>
The codes which ever used these two variables have gone. Throw away
them too.
Signed-off-by: Kevin Hao <haokexin@gmail.com>
---
arch/powerpc/kernel/pci-common.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 8245d51..50fabab 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -671,10 +671,9 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
int rlen;
int pna = of_n_addr_cells(dev);
int np = pna + 5;
- int memno = 0, isa_hole = -1;
+ int memno = 0;
u32 pci_space;
unsigned long long pci_addr, cpu_addr, pci_next, cpu_next, size;
- unsigned long long isa_mb = 0;
struct resource *res;
printk(KERN_INFO "PCI host bridge %s %s ranges:\n",
@@ -768,8 +767,6 @@ void pci_process_bridge_OF_ranges(struct pci_controller *hose,
}
/* Handles ISA memory hole space here */
if (pci_addr == 0) {
- isa_mb = cpu_addr;
- isa_hole = memno;
if (primary || isa_mem_base == 0)
isa_mem_base = cpu_addr;
hose->isa_mem_phys = cpu_addr;
--
1.8.1.4
^ permalink raw reply related
* [PATCH 1/2] powerpc/pci: remove the stale comments of pci_process_bridge_OF_ranges
From: Kevin Hao @ 2013-05-17 6:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc
In-Reply-To: <1368773922-19754-1-git-send-email-haokexin@gmail.com>
These comments already don't apply to the current code. So just remove
them.
Signed-off-by: Kevin Hao <haokexin@gmail.com>
---
arch/powerpc/kernel/pci-common.c | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 6053f03..8245d51 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -657,15 +657,6 @@ void pci_resource_to_user(const struct pci_dev *dev, int bar,
* ranges. However, some machines (thanks Apple !) tend to split their
* space into lots of small contiguous ranges. So we have to coalesce.
*
- * - We can only cope with all memory ranges having the same offset
- * between CPU addresses and PCI addresses. Unfortunately, some bridges
- * are setup for a large 1:1 mapping along with a small "window" which
- * maps PCI address 0 to some arbitrary high address of the CPU space in
- * order to give access to the ISA memory hole.
- * The way out of here that I've chosen for now is to always set the
- * offset based on the first resource found, then override it if we
- * have a different offset and the previous was set by an ISA hole.
- *
* - Some busses have IO space not starting at 0, which causes trouble with
* the way we do our IO resource renumbering. The code somewhat deals with
* it for 64 bits but I would expect problems on 32 bits.
--
1.8.1.4
^ permalink raw reply related
* [PATCH 0/2] two minor cleanup patches for function pci_process_bridge_OF_ranges
From: Kevin Hao @ 2013-05-17 6:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc
Kevin Hao (2):
powerpc/pci: remove the stale comments of pci_process_bridge_OF_ranges
powerpc/pci: remove the unused variables in
pci_process_bridge_OF_ranges
arch/powerpc/kernel/pci-common.c | 14 +-------------
1 file changed, 1 insertion(+), 13 deletions(-)
--
1.8.1.4
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/512x: DMA via LocalPlus Bus testing driver
From: Alexander Popov @ 2013-05-17 6:53 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Arnd Bergmann, devicetree-discuss, Timur Tabi, Rob Herring,
linux-kernel, Paul Mackerras, Grant Likely, Anatolij Gustschin,
linuxppc-dev
In-Reply-To: <20130517011523.GA9555@kroah.com>
2013/5/17 Greg Kroah-Hartman <gregkh@linuxfoundation.org>:
> On Thu, May 02, 2013 at 07:23:15PM +0400, Alexander Popov wrote:
>> This module tests Direct Memory Access to some device on LocalPlus Bus
>> for Freescale MPC512x. In other words it tests the bundle
>> of mpc512x_lpbfifo and mpc512x_dma drivers.
>>
>> This testing driver was multiply used with static RAM (CY62167EV30LL-45ZXI)
>> which lives on LocalPlus Bus on our board. This testing driver was used
>> instead of the original static RAM driver and it is an abnormal hack.
>> That is why I just provide the driver code and don't modify any environment.
>>
>
> You obviously didn't test your testing driver to see if it would build
> in the kernel source tree :(
>
> Care to try again?
Hello Greg,
thanks for your comment.
You are right, this testing driver will not be built in the kernel source tree,
because I intentionally didn't send patches for the corresponding
Makefile, Kconfig and dts.
I would try to explain the reason once again:
I multiply used this testing driver with static RAM (CY62167EV30LL-45ZXI)
to test mpc512x_lpbfifo driver (which is [PATCH 1/2]:
https://patchwork.kernel.org/patch/2511941/ ).
I used this testing driver _instead_ of the original static RAM driver
and it is an abnormal hack.
Because it breaks the usual work of static RAM.
That's why I just provided the code of this testing driver and didn't
modify Makefile, Kconfig and dts.
I hoped that the code of this testing driver will help to review
mpc512x_lpbfifo in the first part of this patch.
Thanks.
Best regards,
Alexander.
^ permalink raw reply
* [PATCH] powerpc/hw_breakpoints: Add DABRX cpu feature
From: Michael Neuling @ 2013-05-17 6:27 UTC (permalink / raw)
To: benh; +Cc: Linux PPC dev, Gorelik, Jacob (335F)
In-Reply-To: <30348.1368764834@ale.ozlabs.ibm.com>
Some CPUs have a DABR but not DABRX. Configuration are:
- No 32bit CPUs have DABRX but some have DABR.
- POWER4+ and below have the DABR but no DABRX.
- 970 and POWER5 and above have DABR and DABRX.
- POWER8 has DAWR, hence no DABRX.
This introduces CPU_FTR_DABRX and sets it on appropriate CPUs. We use
the top 64 bits for CPU FTR bits since only 64 bit CPUs have this.
Processors that don't have the DABRX will still work as they will fall
back to software filtering these breakpoints via perf_exclude_event().
Signed-off-by: Michael Neuling <mikey@neuling.org>
Reported-by: "Gorelik, Jacob (335F)" <jacob.gorelik@jpl.nasa.gov>
cc: stable@vger.kernel.org (v3.9 only)
diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
index 26807e5..6f3887d 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -176,6 +176,7 @@ extern const char *powerpc_base_platform;
#define CPU_FTR_CFAR LONG_ASM_CONST(0x0100000000000000)
#define CPU_FTR_HAS_PPR LONG_ASM_CONST(0x0200000000000000)
#define CPU_FTR_DAWR LONG_ASM_CONST(0x0400000000000000)
+#define CPU_FTR_DABRX LONG_ASM_CONST(0x0800000000000000)
#ifndef __ASSEMBLY__
@@ -394,19 +395,20 @@ extern const char *powerpc_base_platform;
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | CPU_FTR_ARCH_201 | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_CAN_NAP | CPU_FTR_MMCRA | \
CPU_FTR_CP_USE_DCBTZ | CPU_FTR_STCX_CHECKS_ADDRESS | \
- CPU_FTR_HVMODE)
+ CPU_FTR_HVMODE | CPU_FTR_DABRX)
#define CPU_FTRS_POWER5 (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_MMCRA | CPU_FTR_SMT | \
CPU_FTR_COHERENT_ICACHE | CPU_FTR_PURR | \
- CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_POPCNTB)
+ CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_POPCNTB | CPU_FTR_DABRX)
#define CPU_FTRS_POWER6 (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_MMCRA | CPU_FTR_SMT | \
CPU_FTR_COHERENT_ICACHE | \
CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \
CPU_FTR_DSCR | CPU_FTR_UNALIGNED_LD_STD | \
- CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_POPCNTB | CPU_FTR_CFAR)
+ CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_POPCNTB | CPU_FTR_CFAR | \
+ CPU_FTR_DABRX)
#define CPU_FTRS_POWER7 (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | CPU_FTR_ARCH_206 |\
CPU_FTR_MMCRA | CPU_FTR_SMT | \
@@ -415,7 +417,7 @@ extern const char *powerpc_base_platform;
CPU_FTR_DSCR | CPU_FTR_SAO | CPU_FTR_ASYM_SMT | \
CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_POPCNTB | CPU_FTR_POPCNTD | \
CPU_FTR_ICSWX | CPU_FTR_CFAR | CPU_FTR_HVMODE | \
- CPU_FTR_VMX_COPY | CPU_FTR_HAS_PPR)
+ CPU_FTR_VMX_COPY | CPU_FTR_HAS_PPR | CPU_FTR_DABRX)
#define CPU_FTRS_POWER8 (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | CPU_FTR_ARCH_206 |\
CPU_FTR_MMCRA | CPU_FTR_SMT | \
@@ -430,14 +432,15 @@ extern const char *powerpc_base_platform;
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
CPU_FTR_PAUSE_ZERO | CPU_FTR_CELL_TB_BUG | CPU_FTR_CP_USE_DCBTZ | \
- CPU_FTR_UNALIGNED_LD_STD)
+ CPU_FTR_UNALIGNED_LD_STD | CPU_FTR_DABRX)
#define CPU_FTRS_PA6T (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_ALTIVEC_COMP | \
- CPU_FTR_PURR | CPU_FTR_REAL_LE)
+ CPU_FTR_PURR | CPU_FTR_REAL_LE | CPU_FTR_DABRX)
#define CPU_FTRS_COMPATIBLE (CPU_FTR_USE_TB | CPU_FTR_PPCAS_ARCH_V2)
#define CPU_FTRS_A2 (CPU_FTR_USE_TB | CPU_FTR_SMT | CPU_FTR_DBELL | \
- CPU_FTR_NOEXECUTE | CPU_FTR_NODSISRALIGN | CPU_FTR_ICSWX)
+ CPU_FTR_NOEXECUTE | CPU_FTR_NODSISRALIGN | \
+ CPU_FTR_ICSWX | CPU_FTR_DABRX )
#ifdef __powerpc64__
#ifdef CONFIG_PPC_BOOK3E
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index a902723..b0f3e3f 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -399,7 +399,8 @@ static inline int __set_dabr(unsigned long dabr, unsigned long dabrx)
static inline int __set_dabr(unsigned long dabr, unsigned long dabrx)
{
mtspr(SPRN_DABR, dabr);
- mtspr(SPRN_DABRX, dabrx);
+ if (cpu_has_feature(CPU_FTR_DABRX))
+ mtspr(SPRN_DABRX, dabrx);
return 0;
}
#else
^ permalink raw reply related
* Re: powerpc: Hardware breakpoints rewrite to handle non DABR breakpoint registers
From: Michael Neuling @ 2013-05-17 4:27 UTC (permalink / raw)
To: Gorelik, Jacob (335F); +Cc: Linux PPC dev
In-Reply-To: <3F431E22-B7A9-4FCF-B34F-DC171A643E05@jpl.nasa.gov>
Hi,
> I assume you are the right person to ask this question.
Yep I am but adding linuxppc-dev mailing list to CC anyway.
> We are running the Linux kernel version 3.8.13 on a PPC750FX 32-bit
> based board without any problems; however, when I tried to boot
> version 3.9.2 on the same board, I get the following error:
>
> Mount-cache hash table entries: 512
> Oops: Exception in kernel mode, sig: 4 [#1]
> BRE750FX
> Modules linked in:
> NIP: c0007210 LR: c00072ac CTR: c00403c0
> REGS: c039be90 TRAP: 0700 Not tainted (3.9.0-svn1447)
> MSR: 00081032 <ME,IR,DR,RI> CR: 22000082 XER: 00000000
> TASK = c03833a8[0] 'swapper' THREAD: c039a000
> GPR00: c029466c c039bf40 c03833a8 00000000 00000000 00000001 00000000 00000000
> GPR08: c0383fe4 00000000 00000000 00000000 42000022 1001a6e4 00000000 100ce000
> GPR16: 00000000 00000001 00000000 00000024 00000001 c02a0000 c03a0000 c02a0000
> GPR24: c0386864 00000004 c038796c c039a000 cf4303d0 c0386490 c0386490 c03833a8
> NIP [c0007210] set_breakpoint+0x48/0x54
> LR [c00072ac] __switch_to+0x90/0x98
> Call Trace:
> [c039bf40] [c00404e4] pick_next_task_fair+0x124/0x1c0 (unreliable)
> [c039bf60] [c029466c] __schedule+0x17c/0x358
> [c039bfa0] [c0294ad0] schedule_preempt_disabled+0x10/0x20
> [c039bfb0] [c0004090] rest_init+0x60/0x70
> [c039bfc0] [c035ed60] start_kernel+0x2c4/0x2d8
> [c039bff0] [00003438] 0x3438
> Instruction dump:
> 2f890000 81630004 80e30000 5483077e 5484ef7e 91480000 91680004 7c633b78
> 419e000c 7d2903a6 4e800420 7c75fba6 <7c97fba6> 38600000 4e800020 9421ffe0
Last two instruction here are:
7c 75 fb a6 mtspr 1013,r3
7c 97 fb a6 mtspr 1015,r4 ****
The SPR 1015 is the dabrx.
Looking at the 970FX docs, it has the DABR but not DABRX. I didn't
realise that this config ever existed so I'm going to have to code
something up to fix it.
Meanwhile the below should get you going. Let me know if it works.
This patch is not for upstream.
Not-at-all-signed-off-by: Michael Neuling <mikey@neuling.org> :-)
Mikey
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index a902723..df9eb8e 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -399,7 +399,6 @@ static inline int __set_dabr(unsigned long dabr, unsigned lo
static inline int __set_dabr(unsigned long dabr, unsigned long dabrx)
{
mtspr(SPRN_DABR, dabr);
- mtspr(SPRN_DABRX, dabrx);
return 0;
}
#else
^ permalink raw reply related
* Re: [PATCH 2/2] powerpc/512x: DMA via LocalPlus Bus testing driver
From: Greg Kroah-Hartman @ 2013-05-17 1:15 UTC (permalink / raw)
To: Alexander Popov
Cc: Arnd Bergmann, devicetree-discuss, Timur Tabi, Rob Herring,
linux-kernel, Paul Mackerras, Grant Likely, Anatolij Gustschin,
linuxppc-dev
In-Reply-To: <1367508195-2420-1-git-send-email-a13xp0p0v88@gmail.com>
On Thu, May 02, 2013 at 07:23:15PM +0400, Alexander Popov wrote:
> This module tests Direct Memory Access to some device on LocalPlus Bus
> for Freescale MPC512x. In other words it tests the bundle
> of mpc512x_lpbfifo and mpc512x_dma drivers.
>
> This testing driver was multiply used with static RAM (CY62167EV30LL-45ZXI)
> which lives on LocalPlus Bus on our board. This testing driver was used
> instead of the original static RAM driver and it is an abnormal hack.
> That is why I just provide the driver code and don't modify any environment.
>
> Signed-off-by: Alexander Popov <a13xp0p0v88@gmail.com>
> ---
> drivers/misc/mpc512x_lpbdma_test.c | 310 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 310 insertions(+)
> create mode 100644 drivers/misc/mpc512x_lpbdma_test.c
You obviously didn't test your testing driver to see if it would build
in the kernel source tree :(
Care to try again?
^ permalink raw reply
* Re: [PATCH] can: flexcan: allow compilation on arm and powerpc
From: Shawn Guo @ 2013-05-17 2:03 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Arnd Bergmann, Sascha Hauer, U Bhaskar-B22300, linux-kernel,
linux-can, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1368711756-22324-1-git-send-email-mkl@pengutronix.de>
Hi Marc,
On Thu, May 16, 2013 at 03:42:36PM +0200, Marc Kleine-Budde wrote:
> This patch removes the Kconfig symbols HAVE_CAN_FLEXCAN and
> IMX_HAVE_PLATFORM_FLEXCAN from arch/{arm,powerpc} and allowing compilation on
> all arm and powerpc platforms.
I'm generally fine with the approach. But with Kconfig symbol
IMX_HAVE_PLATFORM_FLEXCAN removed, how does the build of
platform-flexcan.o work?
arch/arm/mach-imx/devices/Makefile:obj-$(CONFIG_IMX_HAVE_PLATFORM_FLEXCAN) += platform-flexcan.o
Shawn
^ permalink raw reply
* Re: [PATCH v2 10/10] kernel: might_fault does not imply might_sleep
From: Peter Zijlstra @ 2013-05-16 18:40 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-m32r-ja, kvm, Catalin Marinas, Will Deacon, David Howells,
linux-mm, Paul Mackerras, H. Peter Anvin, linux-arch,
linux-am33-list, Hirokazu Takata, x86, Ingo Molnar, Arnd Bergmann,
microblaze-uclinux, Chris Metcalf, rostedt, Thomas Gleixner,
linux-arm-kernel, Michal Simek, linux-m32r, linux-kernel,
Koichi Yasutake, linuxppc-dev
In-Reply-To: <1f85dc8e6a0149677563a2dfb4cef9a9c7eaa391.1368702323.git.mst@redhat.com>
On Thu, May 16, 2013 at 02:16:10PM +0300, Michael S. Tsirkin wrote:
> There are several ways to make sure might_fault
> calling function does not sleep.
> One is to use it on kernel or otherwise locked memory - apparently
> nfs/sunrpc does this. As noted by Ingo, this is handled by the
> migh_fault() implementation in mm/memory.c but not the one in
> linux/kernel.h so in the current code might_fault() schedules
> differently depending on CONFIG_PROVE_LOCKING, which is an undesired
> semantical side effect.
>
> Another is to call pagefault_disable: in this case the page fault
> handler will go to fixups processing and we get an error instead of
> sleeping, so the might_sleep annotation is a false positive.
> vhost driver wants to do this now in order to reuse socket ops
> under a spinlock (and fall back on slower thread handler
> on error).
Are you using the assumption that spin_lock() implies preempt_disable() implies
pagefault_disable()? Note that this assumption isn't valid for -rt where the
spinlock becomes preemptible but we'll not disable pagefaults.
> Address both issues by:
> - dropping the unconditional call to might_sleep
> from the fast might_fault code in linux/kernel.h
> - checking for pagefault_disable() in the
> CONFIG_PROVE_LOCKING implementation
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> include/linux/kernel.h | 1 -
> mm/memory.c | 14 +++++++++-----
> 2 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index e96329c..322b065 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -198,7 +198,6 @@ void might_fault(void);
> #else
> static inline void might_fault(void)
> {
> - might_sleep();
This removes potential resched points for PREEMPT_VOLUNTARY -- was that
intentional?
> }
> #endif
>
> diff --git a/mm/memory.c b/mm/memory.c
> index 6dc1882..1b8327b 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -4222,13 +4222,17 @@ void might_fault(void)
> if (segment_eq(get_fs(), KERNEL_DS))
> return;
>
> - might_sleep();
> /*
> - * it would be nicer only to annotate paths which are not under
> - * pagefault_disable, however that requires a larger audit and
> - * providing helpers like get_user_atomic.
> + * It would be nicer to annotate paths which are under preempt_disable
> + * but not under pagefault_disable, however that requires a new flag
> + * for differentiating between the two.
-rt has this, pagefault_disable() doesn't change the preempt count but pokes
at task_struct::pagefault_disable.
> */
> - if (!in_atomic() && current->mm)
> + if (in_atomic())
> + return;
> +
> + might_sleep();
> +
> + if (current->mm)
> might_lock_read(¤t->mm->mmap_sem);
> }
> EXPORT_SYMBOL(might_fault);
> --
> MST
^ permalink raw reply
* RE: [PATCH 2/2 v2] powerpc: restore dbcr0 on user space exit
From: Bhushan Bharat-R65777 @ 2013-05-16 17:03 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: Yang James-RA8135, linuxppc-dev@lists.ozlabs.org,
Yoder Stuart-B08248
In-Reply-To: <1368723257.8202.43@snotra>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Thursday, May 16, 2013 10:24 PM
> To: Bhushan Bharat-R65777
> Cc: galak@kernel.crashing.org; benh@kernel.crashing.org; linuxppc-
> dev@lists.ozlabs.org; Yoder Stuart-B08248; Yang James-RA8135; Bhushan Bha=
rat-
> R65777
> Subject: Re: [PATCH 2/2 v2] powerpc: restore dbcr0 on user space exit
>=20
> On 05/16/2013 12:34:32 AM, Bharat Bhushan wrote:
> > On BookE (Branch taken + Single Step) is as same as Branch Taken on
> > BookS and in Linux we simulate BookS behavior for BookE as well.
> > When doing so, in Branch taken handling we want to set DBCR0_IC but we
> > update the current->thread->dbcr0 and not DBCR0.
> >
> > Now on 64bit the current->thread.dbcr0 (and other debug registers) is
> > synchronized ONLY on context switch flow. But after handling Branch
> > taken in debug exception if we return back to user space without
> > context switch then single stepping change (DBCR0_ICMP) does not get
> > written in h/w DBCR0 and Instruction Complete exception does not
> > happen.
> >
> > This fixes using ptrace reliably on BookE-PowerPC
> >
> > Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
> > ---
> > v1->v2
> > - Subject line was not having 2/2
> >
> > arch/powerpc/kernel/asm-offsets.c | 1 +
> > arch/powerpc/kernel/entry_64.S | 24 ++++++++++++++++++++----
> > 2 files changed, 21 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/powerpc/kernel/asm-offsets.c
> > b/arch/powerpc/kernel/asm-offsets.c
> > index b51a97c..1e2f450 100644
> > --- a/arch/powerpc/kernel/asm-offsets.c
> > +++ b/arch/powerpc/kernel/asm-offsets.c
> > @@ -103,6 +103,7 @@ int main(void)
> > #endif /* CONFIG_VSX */
> > #ifdef CONFIG_PPC64
> > DEFINE(KSP_VSID, offsetof(struct thread_struct, ksp_vsid));
> > + DEFINE(THREAD_DBCR0, offsetof(struct thread_struct, dbcr0));
> > #else /* CONFIG_PPC64 */
> > DEFINE(PGDIR, offsetof(struct thread_struct, pgdir)); #if
> > defined(CONFIG_4xx) || defined(CONFIG_BOOKE) diff --git
> > a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
> > index 794889b..561630d 100644
> > --- a/arch/powerpc/kernel/entry_64.S
> > +++ b/arch/powerpc/kernel/entry_64.S
> > @@ -614,7 +614,9 @@ _GLOBAL(ret_from_except_lite)
> > * from the interrupt.
> > */
> > #ifdef CONFIG_PPC_BOOK3E
> > + ld r3,PACACURRENT(r13)
> > wrteei 0
> > + lwz r10,(THREAD+THREAD_DBCR0)(r3)
>=20
> I know I asked you to move these earlier, but this is probably too early.=
..
> wrteei has synchronization, so it will probably have to wait until the ld
> completes, defeating the purpose of moving it earlier.
>=20
> Ideal would probably be to load PACACURRENT immediately after _MSR(r1), a=
nd load
> DBCR0 just after "beq resume_kernel".
ok
>=20
> Or, move DBCR0 to therad_info as I suggested internally.
If no one have objection on moving dbcr0 to thread_info then I am happy to =
do that.
>=20
> Regardless of what you do, could you run a basic syscall benchmark (e.g. =
from
> lmbench) before and after the patch?
Sure.
-Bharat
>=20
> -Scott
^ permalink raw reply
* Re: [PATCH 2/2 v2] powerpc: restore dbcr0 on user space exit
From: Scott Wood @ 2013-05-16 16:54 UTC (permalink / raw)
To: Bharat Bhushan; +Cc: Bharat Bhushan, stuart.yoder, James.Yang, linuxppc-dev
In-Reply-To: <1368682472-4268-3-git-send-email-Bharat.Bhushan@freescale.com>
On 05/16/2013 12:34:32 AM, Bharat Bhushan wrote:
> On BookE (Branch taken + Single Step) is as same as Branch Taken
> on BookS and in Linux we simulate BookS behavior for BookE as well.
> When doing so, in Branch taken handling we want to set DBCR0_IC but
> we update the current->thread->dbcr0 and not DBCR0.
>=20
> Now on 64bit the current->thread.dbcr0 (and other debug registers)
> is synchronized ONLY on context switch flow. But after handling
> Branch taken in debug exception if we return back to user space
> without context switch then single stepping change (DBCR0_ICMP)
> does not get written in h/w DBCR0 and Instruction Complete exception
> does not happen.
>=20
> This fixes using ptrace reliably on BookE-PowerPC
>=20
> Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
> ---
> v1->v2
> - Subject line was not having 2/2
>=20
> arch/powerpc/kernel/asm-offsets.c | 1 +
> arch/powerpc/kernel/entry_64.S | 24 ++++++++++++++++++++----
> 2 files changed, 21 insertions(+), 4 deletions(-)
>=20
> diff --git a/arch/powerpc/kernel/asm-offsets.c =20
> b/arch/powerpc/kernel/asm-offsets.c
> index b51a97c..1e2f450 100644
> --- a/arch/powerpc/kernel/asm-offsets.c
> +++ b/arch/powerpc/kernel/asm-offsets.c
> @@ -103,6 +103,7 @@ int main(void)
> #endif /* CONFIG_VSX */
> #ifdef CONFIG_PPC64
> DEFINE(KSP_VSID, offsetof(struct thread_struct, ksp_vsid));
> + DEFINE(THREAD_DBCR0, offsetof(struct thread_struct, dbcr0));
> #else /* CONFIG_PPC64 */
> DEFINE(PGDIR, offsetof(struct thread_struct, pgdir));
> #if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
> diff --git a/arch/powerpc/kernel/entry_64.S =20
> b/arch/powerpc/kernel/entry_64.S
> index 794889b..561630d 100644
> --- a/arch/powerpc/kernel/entry_64.S
> +++ b/arch/powerpc/kernel/entry_64.S
> @@ -614,7 +614,9 @@ _GLOBAL(ret_from_except_lite)
> * from the interrupt.
> */
> #ifdef CONFIG_PPC_BOOK3E
> + ld r3,PACACURRENT(r13)
> wrteei 0
> + lwz r10,(THREAD+THREAD_DBCR0)(r3)
I know I asked you to move these earlier, but this is probably too =20
early... wrteei has synchronization, so it will probably have to wait =20
until the ld completes, defeating the purpose of moving it earlier.
Ideal would probably be to load PACACURRENT immediately after _MSR(r1), =20
and load DBCR0 just after "beq resume_kernel".
Or, move DBCR0 to therad_info as I suggested internally.
Regardless of what you do, could you run a basic syscall benchmark =20
(e.g. from lmbench) before and after the patch?
-Scott=
^ permalink raw reply
* Re: [PATCH 3/3] perf, x86, lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL
From: Stephane Eranian @ 2013-05-16 15:36 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Michael Neuling, ak@linux.intel.com, LKML, Linux PPC dev,
Ingo Molnar
In-Reply-To: <20130516111634.GA15314@twins.programming.kicks-ass.net>
On Thu, May 16, 2013 at 1:16 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Thu, May 16, 2013 at 08:15:17PM +1000, Michael Neuling wrote:
>> Peter,
>>
>> BTW PowerPC also has the ability to filter on conditional branches. Any
>> chance we could add something like the follow to perf also?
>>
>
> I don't see an immediate problem with that except that we on x86 need to
> implement that in the software filter. Stephane do you see any
> fundamental issue with that?
>
On X86, the LBR cannot filter on conditional in HW. Thus as Peter said, it would
have to be done in SW. I did not add that because I think those branches are
not necessarily useful for tools.
>>
>> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
>> index fb104e5..891c769 100644
>> --- a/include/uapi/linux/perf_event.h
>> +++ b/include/uapi/linux/perf_event.h
>> @@ -157,8 +157,9 @@ enum perf_branch_sample_type {
>> PERF_SAMPLE_BRANCH_ANY_CALL = 1U << 4, /* any call branch */
>> PERF_SAMPLE_BRANCH_ANY_RETURN = 1U << 5, /* any return branch */
>> PERF_SAMPLE_BRANCH_IND_CALL = 1U << 6, /* indirect calls */
>> + PERF_SAMPLE_BRANCH_CONDITIONAL = 1U << 7, /* conditional branches */
>>
>> - PERF_SAMPLE_BRANCH_MAX = 1U << 7, /* non-ABI */
>> + PERF_SAMPLE_BRANCH_MAX = 1U << 8, /* non-ABI */
>> };
>>
>> #define PERF_SAMPLE_BRANCH_PLM_ALL \
>> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
>> index cdf58ec..5b0b89d 100644
>> --- a/tools/perf/builtin-record.c
>> +++ b/tools/perf/builtin-record.c
>> @@ -676,6 +676,7 @@ static const struct branch_mode branch_modes[] = {
>> BRANCH_OPT("any_call", PERF_SAMPLE_BRANCH_ANY_CALL),
>> BRANCH_OPT("any_ret", PERF_SAMPLE_BRANCH_ANY_RETURN),
>> BRANCH_OPT("ind_call", PERF_SAMPLE_BRANCH_IND_CALL),
>> + BRANCH_OPT("cnd", PERF_SAMPLE_BRANCH_CONDITIONAL),
>> BRANCH_END
>> };
>>
^ permalink raw reply
* FW:
From: zhghua0321 @ 2013-05-16 15:28 UTC (permalink / raw)
To: linuxppc-dev
http://www.hazelnuts.it/1cr5if.php
^ permalink raw reply
* Re: SATA FSL and upstreaming
From: Timur Tabi @ 2013-05-16 14:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Xie Shaohui-B21989, Liu Qiang-B32616, Zang Roy-R61911,
tiejun.chen, Fleming Andy-AFLEMING, Bhushan Bharat-R65777,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1368687133.9603.51.camel@pasglop>
On Thu, May 16, 2013 at 1:52 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
>> 3) run " pix altbak" command
>>
>> 4) check you are on bank4
>
> It stays on bank 0
pix altbank
^ permalink raw reply
* [PATCH] can: flexcan: allow compilation on arm and powerpc
From: Marc Kleine-Budde @ 2013-05-16 13:42 UTC (permalink / raw)
To: linux-kernel
Cc: Arnd Bergmann, Sascha Hauer, U Bhaskar-B22300, linux-can,
Marc Kleine-Budde, Shawn Guo, linuxppc-dev, linux-arm-kernel
This patch removes the Kconfig symbols HAVE_CAN_FLEXCAN and
IMX_HAVE_PLATFORM_FLEXCAN from arch/{arm,powerpc} and allowing compilation on
all arm and powerpc platforms.
This brings a bigger compile time coverage and removes the following dependency
warning found by Arnd Bergmann:
warning: (SOC_IMX28 && SOC_IMX25 && SOC_IMX35 && IMX_HAVE_PLATFORM_FLEXCAN &&
SOC_IMX53 && SOC_IMX6Q) selects HAVE_CAN_FLEXCAN
which has unmet direct dependencies (NET && CAN && CAN_DEV)
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Kumar Gala <galak@kernel.crashing.org>
Cc: U Bhaskar-B22300 <B22300@freescale.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
Hello,
if the arm and powerpc people are okay with this, I'm taking this patch (and
then will go upstream via David Miller's net-next).
regards,
Marc
arch/arm/mach-imx/Kconfig | 8 --------
arch/arm/mach-imx/devices/Kconfig | 4 ----
arch/arm/mach-mxs/Kconfig | 1 -
arch/powerpc/Kconfig | 1 -
drivers/net/can/Kconfig | 5 +----
5 files changed, 1 insertion(+), 18 deletions(-)
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index ba44328..239d084 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -111,7 +111,6 @@ config SOC_IMX25
select ARCH_MXC_IOMUX_V3
select COMMON_CLK
select CPU_ARM926T
- select HAVE_CAN_FLEXCAN if CAN
select MXC_AVIC
config SOC_IMX27
@@ -137,7 +136,6 @@ config SOC_IMX35
select ARCH_MXC_IOMUX_V3
select COMMON_CLK
select CPU_V6K
- select HAVE_CAN_FLEXCAN if CAN
select HAVE_EPIT
select MXC_AVIC
select SMP_ON_UP if SMP
@@ -208,7 +206,6 @@ comment "MX25 platforms:"
config MACH_MX25_3DS
bool "Support MX25PDK (3DS) Platform"
- select IMX_HAVE_PLATFORM_FLEXCAN
select IMX_HAVE_PLATFORM_FSL_USB2_UDC
select IMX_HAVE_PLATFORM_IMX2_WDT
select IMX_HAVE_PLATFORM_IMXDI_RTC
@@ -223,7 +220,6 @@ config MACH_MX25_3DS
config MACH_EUKREA_CPUIMX25SD
bool "Support Eukrea CPUIMX25 Platform"
- select IMX_HAVE_PLATFORM_FLEXCAN
select IMX_HAVE_PLATFORM_FSL_USB2_UDC
select IMX_HAVE_PLATFORM_IMX2_WDT
select IMX_HAVE_PLATFORM_IMXDI_RTC
@@ -629,7 +625,6 @@ comment "MX35 platforms:"
config MACH_PCM043
bool "Support Phytec pcm043 (i.MX35) platforms"
- select IMX_HAVE_PLATFORM_FLEXCAN
select IMX_HAVE_PLATFORM_FSL_USB2_UDC
select IMX_HAVE_PLATFORM_IMX2_WDT
select IMX_HAVE_PLATFORM_IMX_I2C
@@ -665,7 +660,6 @@ config MACH_MX35_3DS
config MACH_EUKREA_CPUIMX35SD
bool "Support Eukrea CPUIMX35 Platform"
- select IMX_HAVE_PLATFORM_FLEXCAN
select IMX_HAVE_PLATFORM_FSL_USB2_UDC
select IMX_HAVE_PLATFORM_IMX2_WDT
select IMX_HAVE_PLATFORM_IMX_I2C
@@ -776,7 +770,6 @@ comment "Device tree only"
config SOC_IMX53
bool "i.MX53 support"
- select HAVE_CAN_FLEXCAN if CAN
select HAVE_IMX_SRC
select IMX_HAVE_PLATFORM_IMX2_WDT
select PINCTRL
@@ -799,7 +792,6 @@ config SOC_IMX6Q
select CPU_V7
select HAVE_ARM_SCU if SMP
select HAVE_ARM_TWD if LOCAL_TIMERS
- select HAVE_CAN_FLEXCAN if CAN
select HAVE_IMX_ANATOP
select HAVE_IMX_GPC
select HAVE_IMX_MMDC
diff --git a/arch/arm/mach-imx/devices/Kconfig b/arch/arm/mach-imx/devices/Kconfig
index 3dd2b1b..b0a629d 100644
--- a/arch/arm/mach-imx/devices/Kconfig
+++ b/arch/arm/mach-imx/devices/Kconfig
@@ -2,10 +2,6 @@ config IMX_HAVE_PLATFORM_FEC
bool
default y if ARCH_MX25 || SOC_IMX27 || SOC_IMX35 || SOC_IMX51 || SOC_IMX53
-config IMX_HAVE_PLATFORM_FLEXCAN
- bool
- select HAVE_CAN_FLEXCAN if CAN
-
config IMX_HAVE_PLATFORM_FSL_USB2_UDC
bool
diff --git a/arch/arm/mach-mxs/Kconfig b/arch/arm/mach-mxs/Kconfig
index 4dc2fbb..ce6e7d6 100644
--- a/arch/arm/mach-mxs/Kconfig
+++ b/arch/arm/mach-mxs/Kconfig
@@ -11,7 +11,6 @@ config SOC_IMX28
select ARM_AMBA
select ARM_CPU_SUSPEND if PM
select CPU_ARM926T
- select HAVE_CAN_FLEXCAN if CAN
select HAVE_PWM
select PINCTRL_IMX28
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c33e3ad..7754c6b 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -674,7 +674,6 @@ config SBUS
config FSL_SOC
bool
- select HAVE_CAN_FLEXCAN if NET && CAN
config FSL_PCI
bool
diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
index e456b70..3c06947 100644
--- a/drivers/net/can/Kconfig
+++ b/drivers/net/can/Kconfig
@@ -102,12 +102,9 @@ config CAN_JANZ_ICAN3
This driver can also be built as a module. If so, the module will be
called janz-ican3.ko.
-config HAVE_CAN_FLEXCAN
- bool
-
config CAN_FLEXCAN
tristate "Support for Freescale FLEXCAN based chips"
- depends on HAVE_CAN_FLEXCAN
+ depends on ARM || PPC
---help---
Say Y here if you want to support for Freescale FlexCAN.
--
1.8.2.rc2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox