[PATCH] powerpc: Remove broken GregorianDay()
GregorianDay() is supposed to calculate the day of the week
(tm->tm_wday) for a given day/month/year. In that calcuation it
indexed into an array called MonthOffset using tm->tm_mon-1. However
tm_mon is zero-based, not one-based, so this is off-by-one. It also
means that every January, GregoiranDay() will access element -1 of
the MonthOffset array.
It also doesn't appear to be a correct algorithm either: see in
contrast kernel/time/timeconv.c's time_to_tm function.
It's been broken forever, which suggests no-one in userland uses
this. It looks like no-one in the kernel uses tm->tm_wday either
(see e.g. drivers/rtc/rtc-ds1305.c:319).
tm->tm_wday is conventionally set to -1 when not available in
hardware so we can simply set it to -1 and drop the function.
(There are over a dozen other drivers in drivers/rtc that do
this.)
Found using UBSAN.
Cc: Andrey Ryabinin
Cc: Andrew Morton # as an example of what UBSan
finds.
Cc: Alessandro Zummo
Cc: Alexandre Belloni
Cc: rtc-li...@googlegroups.com
Signed-off-by: Daniel Axtens
---
This is almost entirely a powerpc patch, but it also touches
the OPAL rtc driver. Alessandro, Alexandre, RTC folk, would
you be OK with mpe taking this through the powerpc tree?
I don't think there's any point in sending it to stable
because obviously nothing uses it.
There are a couple of situations where this bug could cause access
before the start of the array:
- Every January, GregoiranDay() will access element -1.
- In drivers/rtc/rtc-opal.c, it's called in via opal_get_tpo_time.
In the case where a timed power on (TPO) is not set, 0 will be
passed to opal_to_tm, which will lead to a month of -1, which will
lead to an access of element -2. (This is how I first found it.)
These are fixed out-of-bounds reads. There are some near misses for
attacker-controlled out-of-bounds reads via to_tm(). It's called in:
- RTAS power on clock - init only
- RTAS clock write - should require you to be root
- ntp's update_persistent_clock. I think we're safe from being given
an arbitrary value here because of ntp_validate_timex in
do_adjtimex, which is ultimately the only callsite, but it's a bit
of a near miss.
- RTC reads in platforms/{8xx,powermac}
- an unused debug function in platforms/ps3
I've done some objdumping on both a -next kernel and a distro kernel,
and it looks like the data immediately before the array is NULL, so
it seems that by good fortune that we aren't going to leak any data
anyway.
---
arch/powerpc/include/asm/time.h | 1 -
arch/powerpc/kernel/time.c| 36 ++-
arch/powerpc/platforms/maple/time.c | 2 +-
arch/powerpc/platforms/powernv/opal-rtc.c | 3 +--
drivers/rtc/rtc-opal.c| 2 +-
5 files changed, 5 insertions(+), 39 deletions(-)
diff --git a/arch/powerpc/include/asm/time.h b/arch/powerpc/include/asm/time.h
index 10fc784a2ad4..2d7109a8d296 100644
--- a/arch/powerpc/include/asm/time.h
+++ b/arch/powerpc/include/asm/time.h
@@ -27,7 +27,6 @@ extern struct clock_event_device decrementer_clockevent;
struct rtc_time;
extern void to_tm(int tim, struct rtc_time * tm);
-extern void GregorianDay(struct rtc_time *tm);
extern void tick_broadcast_ipi_handler(void);
extern void generic_calibrate_decr(void);
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 1be1092c7204..81b0900a39ee 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -1002,38 +1002,6 @@ static int month_days[12] = {
31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31
};
-/*
- * This only works for the Gregorian calendar - i.e. after 1752 (in the UK)
- */
-void GregorianDay(struct rtc_time * tm)
-{
- int leapsToDate;
- int lastYear;
- int day;
- int MonthOffset[] = { 0, 31, 59, 90, 120, 151, 181, 212, 243, 273, 304,
334 };
-
- lastYear = tm->tm_year - 1;
-
- /*
-* Number of leap corrections to apply up to end of last year
-*/
- leapsToDate = lastYear / 4 - lastYear / 100 + lastYear / 400;
-
- /*
-* This year is a leap year if it is divisible by 4 except when it is
-* divisible by 100 unless it is divisible by 400
-*
-* e.g. 1904 was a leap year, 1900 was not, 1996 is, and 2000 was
-*/
- day = tm->tm_mon > 2 && leapyear(tm->tm_year);
-
- day += lastYear*365 + leapsToDate + MonthOffset[tm->tm_mon-1] +
- tm->tm_mday;
-
- tm->tm_wday = day % 7;
-}
-EXPORT_SYMBOL_GPL(GregorianDay);
-
void to_tm(int tim, struct rtc_time * tm)
{
register inti;
@@ -1064,9 +1032,9 @@ void to_tm(int tim, struct rtc_time * tm)
tm->tm_mday = day + 1;
/*
-* Determine the day of week
+* No-one uses the day of the week.
*/
- GregorianDay(tm);
+ tm->tm_wday = -1;
}
EXPORT_SYMBOL(to_tm);
diff --git a/arch/powerpc/platforms/maple/time.c
b/arch/powerpc/platforms/ma
Re: [PATCH] powerpc: Enable UBSAN support
>> Have you tried running with KVM? OK, I ran a UBSAN kvm guest on a UBSAN host and I ran trinity inside the guest. It all appears to work as usual. I really don't have the knowledge to determine what we should exclude, but I'm very very happy to respin with a greater list of excludes if you think that's a good idea. Regards, Daniel >> >> I'm wondering if we should be excluding some of the KVM code that runs in >> real mode, eg: >> >> arch/powerpc/kvm/book3s_hv_rm_mmu.c >> arch/powerpc/kvm/book3s_hv_rm_xics.c >> >> And maybe some other bits. >> >> Also the early setup code, a/p/k/setup*.c might be dicey. > > My philosphy was just to copy the GCOV excludes, although you're right > that perhaps we want to be more aggressive in excluding here given that > the UBSAN handlers print a bunch of stuff. I'm happy to respin with > further exclusions - they're really easy to add. > >> In all of the above it's probably OK unless you actually hit a warning at the >> wrong point, so testing will probably not find problems. Although I guess we >> could add some deliberatly incorrect code at certain points and check we >> survive the warning. > > Yep. I'll run a kvm guest on an instrumented kernel and let you know > what happens! > >> >> Is there an easy way to spot the calls to UBSAN in the generated code? > > Yes - because of the handler functions, they're *really* easy to spot. > Here's some assembly for GregorianDay(): > > > c002924c: 6d 26 7e 48 bl c080b8b8 > <__ubsan_handle_mul_overflow+0x8> > c0029250: 00 00 00 60 nop > c0029254: 38 fe ff 4b b c002908c > > c0029258: 8c ff 62 3c addis r3,r2,-116 > c002925c: 01 00 a0 38 li r5,1 > c0029260: 78 db 64 7f mr r4,r27 > c0029264: 50 9c 63 38 addir3,r3,-25520 > c0029268: 41 26 7e 48 bl c080b8a8 > <__ubsan_handle_sub_overflow+0x8> > c002926c: 00 00 00 60 nop > c0029270: 44 fe ff 4b b c00290b4 > > c0029274: 8c ff 62 3c addis r3,r2,-116 > c0029278: 78 d3 45 7f mr r5,r26 > c002927c: e0 9c 63 38 addir3,r3,-25376 > c0029280: 19 26 7e 48 bl c080b898 > <__ubsan_handle_add_overflow+0x8> > c0029284: 00 00 00 60 nop > c0029288: 94 fe ff 4b b c002911c > > c002928c: 8c ff 62 3c addis r3,r2,-116 > c0029290: 78 f3 c4 7f mr r4,r30 > c0029294: 68 9c 63 38 addir3,r3,-25496 > c0029298: b1 21 7e 48 bl c080b448 > <__ubsan_handle_out_of_bounds+0x8> > c002929c: 00 00 00 60 nop > c00292a0: 20 fe ff 4b b c00290c0 > > c00292a4: 14 4a 24 7d add r9,r4,r9 > c00292a8: 40 48 a4 7f cmpld cr7,r4,r9 > c00292ac: 2c fe fd 41 bgt+cr7,c00290d8 > > > You can see that there are lots of calls to __ubsan_handle_blah_blah > inserted. > > Regards, > Daniel > >> >> cheers >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: manual merge of the akpm-current tree with the powerpc tree
Hi Andrew, On Tue, 15 Dec 2015 16:53:42 +1100 Stephen Rothwell wrote: > > diff --git a/arch/powerpc/include/asm/book3s/64/hash.h > b/arch/powerpc/include/asm/book3s/64/hash.h > index 8b929e531758..4e69d9a273ed 100644 > --- a/arch/powerpc/include/asm/book3s/64/hash.h > +++ b/arch/powerpc/include/asm/book3s/64/hash.h > @@ -48,9 +43,8 @@ > /* > * set of bits not changed in pmd_modify. > */ > -#define _HPAGE_CHG_MASK (PTE_RPN_MASK | _PAGE_HPTEFLAGS |\ > - _PAGE_DIRTY | _PAGE_ACCESSED | _PAGE_SPLITTING | \ > - _PAGE_THP_HUGE | _PAGE_PTE) > +#define _HPAGE_CHG_MASK (PTE_RPN_MASK | _PAGE_HPTEFLAGS | _PAGE_DIRTY | ^ I missed a backslash here which I fixed up in my tree. > + _PAGE_ACCESSED | _PAGE_THP_HUGE | _PAGE_PTE) -- Cheers, Stephen Rothwells...@canb.auug.org.au ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: manual merge of the akpm-current tree with the powerpc tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got conflicts in:
arch/powerpc/include/asm/nohash/64/pgtable.h
arch/powerpc/mm/pgtable_64.c
between various commits from the powerpc tree and commits:
e56ebae0dd4c ("powerpc, thp: remove infrastructure for handling splitting
PMDs")
from the akpm-current tree.
I used the powerpc tree version of the first and the akpm-current tree
version of the second and then I applied the following merge fix patch:
From: Stephen Rothwell
Date: Tue, 15 Dec 2015 16:50:42 +1100
Subject: [PATCH] merge fix for "powerpc, thp: remove infrastructure for
handling splitting PMDs"
Signed-off-by: Stephen Rothwell
---
arch/powerpc/include/asm/book3s/64/hash-64k.h | 12
arch/powerpc/include/asm/book3s/64/hash.h | 10 ++
arch/powerpc/include/asm/book3s/64/pgtable.h | 4
3 files changed, 2 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/64/hash-64k.h
b/arch/powerpc/include/asm/book3s/64/hash-64k.h
index 9f9942998587..f2072a4ca9e3 100644
--- a/arch/powerpc/include/asm/book3s/64/hash-64k.h
+++ b/arch/powerpc/include/asm/book3s/64/hash-64k.h
@@ -256,13 +256,6 @@ static inline int pmd_trans_huge(pmd_t pmd)
(_PAGE_PTE | _PAGE_THP_HUGE));
}
-static inline int pmd_trans_splitting(pmd_t pmd)
-{
- if (pmd_trans_huge(pmd))
- return pmd_val(pmd) & _PAGE_SPLITTING;
- return 0;
-}
-
static inline int pmd_large(pmd_t pmd)
{
return !!(pmd_val(pmd) & _PAGE_PTE);
@@ -273,11 +266,6 @@ static inline pmd_t pmd_mknotpresent(pmd_t pmd)
return __pmd(pmd_val(pmd) & ~_PAGE_PRESENT);
}
-static inline pmd_t pmd_mksplitting(pmd_t pmd)
-{
- return __pmd(pmd_val(pmd) | _PAGE_SPLITTING);
-}
-
#define __HAVE_ARCH_PMD_SAME
static inline int pmd_same(pmd_t pmd_a, pmd_t pmd_b)
{
diff --git a/arch/powerpc/include/asm/book3s/64/hash.h
b/arch/powerpc/include/asm/book3s/64/hash.h
index 8b929e531758..4e69d9a273ed 100644
--- a/arch/powerpc/include/asm/book3s/64/hash.h
+++ b/arch/powerpc/include/asm/book3s/64/hash.h
@@ -35,11 +35,6 @@
#define _PAGE_SPECIAL 0x1 /* software: special page */
/*
- * THP pages can't be special. So use the _PAGE_SPECIAL
- */
-#define _PAGE_SPLITTING _PAGE_SPECIAL
-
-/*
* We need to differentiate between explicit huge page and THP huge
* page, since THP huge page also need to track real subpage details
*/
@@ -48,9 +43,8 @@
/*
* set of bits not changed in pmd_modify.
*/
-#define _HPAGE_CHG_MASK (PTE_RPN_MASK | _PAGE_HPTEFLAGS | \
-_PAGE_DIRTY | _PAGE_ACCESSED | _PAGE_SPLITTING | \
-_PAGE_THP_HUGE | _PAGE_PTE)
+#define _HPAGE_CHG_MASK (PTE_RPN_MASK | _PAGE_HPTEFLAGS | _PAGE_DIRTY |
+_PAGE_ACCESSED | _PAGE_THP_HUGE | _PAGE_PTE)
#ifdef CONFIG_PPC_64K_PAGES
#include
diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h
b/arch/powerpc/include/asm/book3s/64/pgtable.h
index a2d4e0e37067..6306d6565ee0 100644
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -232,10 +232,6 @@ extern int pmdp_clear_flush_young(struct vm_area_struct
*vma,
extern pmd_t pmdp_huge_get_and_clear(struct mm_struct *mm,
unsigned long addr, pmd_t *pmdp);
-#define __HAVE_ARCH_PMDP_SPLITTING_FLUSH
-extern void pmdp_splitting_flush(struct vm_area_struct *vma,
-unsigned long address, pmd_t *pmdp);
-
extern pmd_t pmdp_collapse_flush(struct vm_area_struct *vma,
unsigned long address, pmd_t *pmdp);
#define pmdp_collapse_flush pmdp_collapse_flush
--
2.6.2
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Enable UBSAN support
Michael Ellerman writes: > Hi Daniel, > > Great work thanks for getting this going. > > Have you tried running with KVM? > > I'm wondering if we should be excluding some of the KVM code that runs in > real mode, eg: > > arch/powerpc/kvm/book3s_hv_rm_mmu.c > arch/powerpc/kvm/book3s_hv_rm_xics.c > > And maybe some other bits. > > Also the early setup code, a/p/k/setup*.c might be dicey. My philosphy was just to copy the GCOV excludes, although you're right that perhaps we want to be more aggressive in excluding here given that the UBSAN handlers print a bunch of stuff. I'm happy to respin with further exclusions - they're really easy to add. > In all of the above it's probably OK unless you actually hit a warning at the > wrong point, so testing will probably not find problems. Although I guess we > could add some deliberatly incorrect code at certain points and check we > survive the warning. Yep. I'll run a kvm guest on an instrumented kernel and let you know what happens! > > Is there an easy way to spot the calls to UBSAN in the generated code? Yes - because of the handler functions, they're *really* easy to spot. Here's some assembly for GregorianDay(): c002924c: 6d 26 7e 48 bl c080b8b8 <__ubsan_handle_mul_overflow+0x8> c0029250: 00 00 00 60 nop c0029254: 38 fe ff 4b b c002908c c0029258: 8c ff 62 3c addis r3,r2,-116 c002925c: 01 00 a0 38 li r5,1 c0029260: 78 db 64 7f mr r4,r27 c0029264: 50 9c 63 38 addir3,r3,-25520 c0029268: 41 26 7e 48 bl c080b8a8 <__ubsan_handle_sub_overflow+0x8> c002926c: 00 00 00 60 nop c0029270: 44 fe ff 4b b c00290b4 c0029274: 8c ff 62 3c addis r3,r2,-116 c0029278: 78 d3 45 7f mr r5,r26 c002927c: e0 9c 63 38 addir3,r3,-25376 c0029280: 19 26 7e 48 bl c080b898 <__ubsan_handle_add_overflow+0x8> c0029284: 00 00 00 60 nop c0029288: 94 fe ff 4b b c002911c c002928c: 8c ff 62 3c addis r3,r2,-116 c0029290: 78 f3 c4 7f mr r4,r30 c0029294: 68 9c 63 38 addir3,r3,-25496 c0029298: b1 21 7e 48 bl c080b448 <__ubsan_handle_out_of_bounds+0x8> c002929c: 00 00 00 60 nop c00292a0: 20 fe ff 4b b c00290c0 c00292a4: 14 4a 24 7d add r9,r4,r9 c00292a8: 40 48 a4 7f cmpld cr7,r4,r9 c00292ac: 2c fe fd 41 bgt+cr7,c00290d8 You can see that there are lots of calls to __ubsan_handle_blah_blah inserted. Regards, Daniel > > cheers > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Enable UBSAN support
Hi Daniel, Great work thanks for getting this going. On Tue, 2015-12-15 at 14:46 +1100, Daniel Axtens wrote: > This hooks up UBSAN support for PowerPC. > > So far it's found some interesting cases where we don't properly sanitise > input to shifts, including one in our futex handling. It's also found an > out of bounds read in an array. Nothing critical, but worth fixing. > > Tested-by: Andrew Donnellan > CC: Andrey Ryabinin > Signed-off-by: Daniel Axtens > --- > > RFC -> v1: > - Update patch to use fixed spelling of SANITIZE. > - Include tested by tag from Andrew - Thanks! > > This applies on top of next with Andrey's patches: > 1) https://patchwork.kernel.org/patch/7761341/ > 2) https://patchwork.kernel.org/patch/7761351/ > 3) https://patchwork.kernel.org/patch/7761361/ > 4) https://patchwork.kernel.org/patch/7785791/ > 5) https://patchwork.kernel.org/patch/7819661/ > > -mm and therefore -next have these patches, and the RFC of this > patch. > > This has now been tested on LE and BE 64bit, on pseries, bml and > PowerNV. Have you tried running with KVM? I'm wondering if we should be excluding some of the KVM code that runs in real mode, eg: arch/powerpc/kvm/book3s_hv_rm_mmu.c arch/powerpc/kvm/book3s_hv_rm_xics.c And maybe some other bits. Also the early setup code, a/p/k/setup*.c might be dicey. In all of the above it's probably OK unless you actually hit a warning at the wrong point, so testing will probably not find problems. Although I guess we could add some deliberatly incorrect code at certain points and check we survive the warning. Is there an easy way to spot the calls to UBSAN in the generated code? cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Enable UBSAN support
This hooks up UBSAN support for PowerPC. So far it's found some interesting cases where we don't properly sanitise input to shifts, including one in our futex handling. It's also found an out of bounds read in an array. Nothing critical, but worth fixing. Tested-by: Andrew Donnellan CC: Andrey Ryabinin Signed-off-by: Daniel Axtens --- RFC -> v1: - Update patch to use fixed spelling of SANITIZE. - Include tested by tag from Andrew - Thanks! This applies on top of next with Andrey's patches: 1) https://patchwork.kernel.org/patch/7761341/ 2) https://patchwork.kernel.org/patch/7761351/ 3) https://patchwork.kernel.org/patch/7761361/ 4) https://patchwork.kernel.org/patch/7785791/ 5) https://patchwork.kernel.org/patch/7819661/ -mm and therefore -next have these patches, and the RFC of this patch. This has now been tested on LE and BE 64bit, on pseries, bml and PowerNV. --- arch/powerpc/Kconfig| 1 + arch/powerpc/kernel/Makefile| 8 +++- arch/powerpc/kernel/vdso32/Makefile | 1 + arch/powerpc/kernel/vdso64/Makefile | 1 + arch/powerpc/xmon/Makefile | 1 + 5 files changed, 11 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 25283796a02e..171d4e4b015d 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -156,6 +156,7 @@ config PPC select EDAC_ATOMIC_SCRUB select ARCH_HAS_DMA_SET_COHERENT_MASK select HAVE_ARCH_SECCOMP_FILTER + select ARCH_HAS_UBSAN_SANITIZE_ALL config GENERIC_CSUM def_bool CPU_LITTLE_ENDIAN diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile index ba336930d448..794f22adf99d 100644 --- a/arch/powerpc/kernel/Makefile +++ b/arch/powerpc/kernel/Makefile @@ -136,12 +136,18 @@ endif obj-$(CONFIG_EPAPR_PARAVIRT) += epapr_paravirt.o epapr_hcalls.o obj-$(CONFIG_KVM_GUEST)+= kvm.o kvm_emul.o -# Disable GCOV in odd or sensitive code +# Disable GCOV & sanitizers in odd or sensitive code GCOV_PROFILE_prom_init.o := n +UBSAN_SANITIZE_prom_init.o := n GCOV_PROFILE_ftrace.o := n +UBSAN_SANITIZE_ftrace.o := n GCOV_PROFILE_machine_kexec_64.o := n +UBSAN_SANITIZE_machine_kexec_64.o := n GCOV_PROFILE_machine_kexec_32.o := n +UBSAN_SANITIZE_machine_kexec_32.o := n GCOV_PROFILE_kprobes.o := n +UBSAN_SANITIZE_kprobes.o := n +UBSAN_SANITIZE_vdso.o := n extra-$(CONFIG_PPC_FPU)+= fpu.o extra-$(CONFIG_ALTIVEC)+= vector.o diff --git a/arch/powerpc/kernel/vdso32/Makefile b/arch/powerpc/kernel/vdso32/Makefile index 6abffb7a8cd9..cbabd143acae 100644 --- a/arch/powerpc/kernel/vdso32/Makefile +++ b/arch/powerpc/kernel/vdso32/Makefile @@ -15,6 +15,7 @@ targets := $(obj-vdso32) vdso32.so vdso32.so.dbg obj-vdso32 := $(addprefix $(obj)/, $(obj-vdso32)) GCOV_PROFILE := n +UBSAN_SANITIZE := n ccflags-y := -shared -fno-common -fno-builtin ccflags-y += -nostdlib -Wl,-soname=linux-vdso32.so.1 \ diff --git a/arch/powerpc/kernel/vdso64/Makefile b/arch/powerpc/kernel/vdso64/Makefile index 8c8f2ae43935..c710802b8fb6 100644 --- a/arch/powerpc/kernel/vdso64/Makefile +++ b/arch/powerpc/kernel/vdso64/Makefile @@ -8,6 +8,7 @@ targets := $(obj-vdso64) vdso64.so vdso64.so.dbg obj-vdso64 := $(addprefix $(obj)/, $(obj-vdso64)) GCOV_PROFILE := n +UBSAN_SANITIZE := n ccflags-y := -shared -fno-common -fno-builtin ccflags-y += -nostdlib -Wl,-soname=linux-vdso64.so.1 \ diff --git a/arch/powerpc/xmon/Makefile b/arch/powerpc/xmon/Makefile index 1278788d96e3..436062dbb6e2 100644 --- a/arch/powerpc/xmon/Makefile +++ b/arch/powerpc/xmon/Makefile @@ -3,6 +3,7 @@ subdir-ccflags-$(CONFIG_PPC_WERROR) := -Werror GCOV_PROFILE := n +UBSAN_SANITIZE := n ccflags-$(CONFIG_PPC64) := $(NO_MINIMAL_TOC) -- 2.6.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 2/3] tools: Move Makefile.arch from perf/config to tools/scripts
After this patch other directories can use this architecture detector
without directly including it from perf's directory. Libbpf would
utilize it to get proper $(ARCH) so it can receive correct uapi include
directory.
Signed-off-by: Wang Nan
Cc: Arnaldo Carvalho de Melo
Cc: Naveen N. Rao
Cc: Jiri Olsa
Cc: Sukadev Bhattiprolu
---
tools/perf/config/Makefile | 2 +-
tools/perf/tests/make| 2 +-
tools/{perf/config => scripts}/Makefile.arch | 0
3 files changed, 2 insertions(+), 2 deletions(-)
rename tools/{perf/config => scripts}/Makefile.arch (100%)
diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index a552417..34717e4 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -17,7 +17,7 @@ detected_var = $(shell echo "$(1)=$($(1))" >>
$(OUTPUT).config-detected)
CFLAGS := $(EXTRA_CFLAGS) $(EXTRA_WARNINGS)
-include $(src-perf)/config/Makefile.arch
+include $(srctree)/tools/scripts/Makefile.arch
$(call detected_var,ARCH)
diff --git a/tools/perf/tests/make b/tools/perf/tests/make
index 8ea3dff..cd9c3ce 100644
--- a/tools/perf/tests/make
+++ b/tools/perf/tests/make
@@ -12,7 +12,7 @@ endif
else
PERF := .
-include config/Makefile.arch
+include $(srctree)/scripts/Makefile.arch
# FIXME looks like x86 is the only arch running tests ;-)
# we need some IS_(32/64) flag to make this generic
diff --git a/tools/perf/config/Makefile.arch b/tools/scripts/Makefile.arch
similarity index 100%
rename from tools/perf/config/Makefile.arch
rename to tools/scripts/Makefile.arch
--
1.8.3.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 1/3] perf tools: Fix PowerPC native building
Checks BPF syscall number, turn off libbpf building on platform doesn't
correctly support sys_bpf instead of blocking compiling.
Reported-by: Naveen N. Rao
Signed-off-by: Wang Nan
Cc: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: Sukadev Bhattiprolu
---
tools/build/feature/test-bpf.c | 20 +++-
tools/lib/bpf/bpf.c| 4 ++--
2 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/tools/build/feature/test-bpf.c b/tools/build/feature/test-bpf.c
index 062bac8..b389026 100644
--- a/tools/build/feature/test-bpf.c
+++ b/tools/build/feature/test-bpf.c
@@ -1,9 +1,23 @@
+#include
#include
+#include
+
+#ifndef __NR_bpf
+# if defined(__i386__)
+# define __NR_bpf 357
+# elif defined(__x86_64__)
+# define __NR_bpf 321
+# elif defined(__aarch64__)
+# define __NR_bpf 280
+# error __NR_bpf not defined. libbpf does not support your arch.
+# endif
+#endif
int main(void)
{
union bpf_attr attr;
+ /* Check fields in attr */
attr.prog_type = BPF_PROG_TYPE_KPROBE;
attr.insn_cnt = 0;
attr.insns = 0;
@@ -14,5 +28,9 @@ int main(void)
attr.kern_version = 0;
attr = attr;
- return 0;
+ /*
+* Test existence of __NR_bpf and BPF_PROG_LOAD.
+* This call should fail if we run the testcase.
+*/
+ return syscall(__NR_bpf, BPF_PROG_LOAD, attr, sizeof(attr));
}
diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
index 5bdc6ea..1f91cc9 100644
--- a/tools/lib/bpf/bpf.c
+++ b/tools/lib/bpf/bpf.c
@@ -14,8 +14,8 @@
#include "bpf.h"
/*
- * When building perf, unistd.h is override. Define __NR_bpf is
- * required to be defined.
+ * When building perf, unistd.h is overrided. __NR_bpf is
+ * required to be defined explicitly.
*/
#ifndef __NR_bpf
# if defined(__i386__)
--
1.8.3.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 3/3] perf: bpf: Fix build breakage due to libbpf
From: "Naveen N. Rao"
perf build is currently (v4.4-rc5) broken on powerpc:
bpf.c:28:4: error: #error __NR_bpf not defined. libbpf does not support
your arch.
# error __NR_bpf not defined. libbpf does not support your arch.
^
Fix this by including tools/perf/config/Makefile.arch for the proper
$ARCH macro. While at it, remove redundant LP64 macro definition.
Signed-off-by: Naveen N. Rao
Signed-off-by: Wang Nan
Cc: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: Sukadev Bhattiprolu
---
tools/lib/bpf/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
index 636e3dd..3d34a8c 100644
--- a/tools/lib/bpf/Makefile
+++ b/tools/lib/bpf/Makefile
@@ -31,7 +31,8 @@ INSTALL = install
DESTDIR ?=
DESTDIR_SQ = '$(subst ','\'',$(DESTDIR))'
-LP64 := $(shell echo __LP64__ | ${CC} ${CFLAGS} -E -x c - | tail -n 1)
+include $(srctree)/tools/scripts/Makefile.arch
+
ifeq ($(LP64), 1)
libdir_relative = lib64
else
--
1.8.3.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 0/3] perf build: PowerPC: Fix build breakage due to libbpf
Hi Naveen,
Now I know your problem is in native building and the reason is
missing proper $(ARCH). I think other than that there's another problem
in libbpf's building: if your problem is unable to compile libbpf,
feature checker should find it and set NO_LIBBPF=1 for perf, so perf
building won't be blocked, only BPF related features should be turned
off. Also, I think including Makefile.arch from tools/scripts would be
better, because libbpf is at the same level with perf. So I separate
them into 3 patches. Please help me test it on PowerPC.
Cc: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: Naveen N. Rao
Cc: Sukadev Bhattiprolu
Naveen N. Rao (1):
perf: bpf: Fix build breakage due to libbpf
Wang Nan (2):
perf tools: Fix PowerPC native building
tools: Move Makefile.arch from perf/config to tools/scripts
tools/build/feature/test-bpf.c | 20 +++-
tools/lib/bpf/Makefile | 3 ++-
tools/lib/bpf/bpf.c | 4 ++--
tools/perf/config/Makefile | 2 +-
tools/perf/tests/make| 2 +-
tools/{perf/config => scripts}/Makefile.arch | 0
6 files changed, 25 insertions(+), 6 deletions(-)
rename tools/{perf/config => scripts}/Makefile.arch (100%)
--
1.8.3.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] 82xx: FCC: Fixing a bug causing to FCC port lock-up
The patch fixes FCC port lock-up, which occurs as a result of a bug during underrun/collision handling. Within the tx_startup() function in mac-fcc.c, the address of last BD is not calculated correctly. As a result of wrong calculation of the last BD address, the next transmitted BD may be set to an area out of the transmit BD ring. This actually causes to port lock-up and it is not recoverable. Signed-off-by: Martin Roth --- drivers/net/ethernet/freescale/fs_enet/mac-fcc.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/freescale/fs_enet/mac-fcc.c b/drivers/net/ethernet/freescale/fs_enet/mac-fcc.c index 08f5b91..52e0091 100644 --- a/drivers/net/ethernet/freescale/fs_enet/mac-fcc.c +++ b/drivers/net/ethernet/freescale/fs_enet/mac-fcc.c @@ -552,7 +552,7 @@ static void tx_restart(struct net_device *dev) cbd_t __iomem *prev_bd; cbd_t __iomem *last_tx_bd; - last_tx_bd = fep->tx_bd_base + (fpi->tx_ring * sizeof(cbd_t)); + last_tx_bd = fep->tx_bd_base + ((fpi->tx_ring - 1) * sizeof(cbd_t)); /* get the current bd held in TBPTR and scan back from this point */ recheck_bd = curr_tbptr = (cbd_t __iomem *) -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 6/6] cxlflash: Enable device id for future IBM CXL adapter
On 15/12/15 08:07, Uma Krishnan wrote: From: Manoj Kumar This drop enables a future card with a device id of 0x0600 to be recognized by the cxlflash driver. If you do a V3 - this could be better worded in the imperative mood as: "Add a new device ID (0x0600) for a future IBM CXL Flash Adapter card." As per the design, the Accelerator Function Unit (AFU) for this new IBM CXL Flash Adapter retains the same host interface as the previous generation. For the early prototypes of the new card, the driver with this change behaves exactly as the driver prior to this behaved with the earlier generation card. Therefore, no card specific programming has been added. These card specific changes can be staged in later if needed. Signed-off-by: Manoj N. Kumar Acked-by: Matthew R. Ochs Assuming that the final card won't break in a particularly nasty way in the absence of later code changes, all looks good. Reviewed-by: Andrew Donnellan -- Andrew Donnellan Software Engineer, OzLabs andrew.donnel...@au1.ibm.com Australia Development Lab, Canberra +61 2 6201 8874 (work)IBM Australia Limited ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v2] platforms/powernv: Add support for Nvlink NPUs
Thanks for the review Michael. I'll do a respin to address the comments below.
On Mon, 14 Dec 2015 20:26:27 Michael Ellerman wrote:
> Hi Alistair,
>
> Just a few nitty things ...
>
> On Tue, 2015-10-11 at 02:28:11 UTC, Alistair Popple wrote:
> > NV-Link is a high speed interconnect that is used in conjunction with
>
> Is it NV-Link or NVLink?
I've seen NV-Link, NVLink and NVLINK in various bits of documentation and
probably used a mixture of those variations myself. Will standardise on NVLink
for OPAL and Linux.
> > a PCI-E connection to create an interface between CPU and GPU that
> > provides very high data bandwidth. A PCI-E connection to a GPU is used
> > as the control path to initiate and report status of large data
> > transfers sent via the NV-Link.
> >
> > On IBM Power systems the NV-Link hardware interface is very similar to
> > the existing PHB3. This patch adds support for this new NPU PHB
>
> NPU ?
NVLink Processing Unit.
> > type. DMA operations on the NPU are not supported as this patch sets
> > the TCE translation tables to be the same as the related GPU PCIe
> > device for each Nvlink. Therefore all DMA operations are setup and
> > controlled via the PCIe device.
> >
> > EEH is not presently supported for the NPU devices, although it may be
> > added in future.
> >
> > Signed-off-by: Alistair Popple
> > Signed-off-by: Gavin Shan
> > ---
> > new file mode 100644
> > index 000..a1e5ba5
> > --- /dev/null
> > +++ b/arch/powerpc/platforms/powernv/npu-dma.c
> > @@ -0,0 +1,339 @@
> > +/*
> > + * This file implements the DMA operations for Nvlink devices. The NPU
> > + * devices all point to the same iommu table as the parent PCI device.
> > + *
> > + * Copyright Alistair Popple, IBM Corporation 2015.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
it
> > + * under the terms of the GNU General Public License as published by
the
> > + * Free Software Foundation; either version 2 of the License, or (at
your
> > + * option) any later version.
>
> Can you drop the any later part, that's not generally true, see COPYING.
>
> eg:
>
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of version 2 of the GNU Lesser General Public License
> + * as published by the Free Software Foundation.
Good point.
> > +
> > +/* Returns the PE assoicated with the PCI device of the given
> > + * NPU. Returns the linked pci device if pci_dev != NULL.
> > + */
>
> Can you reformat all your block comments the right way:
>
> > +/*
> > + * Returns the PE assoicated with the PCI device of the given
> > + * NPU. Returns the linked pci device if pci_dev != NULL.
> > + */
Sure.
> > +static struct pnv_ioda_pe *get_gpu_pci_dev_and_pe(struct pnv_ioda_pe
*npe,
> > + struct pci_dev **gpdev)
> > +{
> > + struct pnv_phb *phb;
> > + struct pci_controller *hose;
>
> I thought we were trying to use phb rather than hose these days, but dunno.
I'm not sure I follow - what do you mean here?
hose = pci_bus_to_host(pdev->bus);
phb = hose->private_data;
Seems to be a fairly typical pattern in pci-ioda.c to get the struct pnv_phb
from a struct pci_dev. Is there an alternative I should be using instead?
> > + struct pci_dev *pdev;
> > + struct pnv_ioda_pe *pe;
> > + struct pci_dn *pdn;
> > +
> > + if (npe->flags & PNV_IODA_PE_PEER) {
> > + pe = npe->peers[0];
> > + pdev = pe->pdev;
> > + } else {
> > + pdev = pnv_pci_get_gpu_dev(npe->pdev);
> > + if (!pdev)
> > + return NULL;
> > +
> > + pdn = pci_get_pdn(pdev);
> > + if (WARN_ON(!pdn || pdn->pe_number == IODA_INVALID_PE))
> > + return NULL;
> > +
> > + hose = pci_bus_to_host(pdev->bus);
> > + phb = hose->private_data;
> > + pe = &phb->ioda.pe_array[pdn->pe_number];
> > + }
> > +
> > + if (gpdev)
> > + *gpdev = pdev;
> > +
> > + return pe;
> > +}
> > +
> > +void pnv_npu_tce_invalidate_entire(struct pnv_ioda_pe *npe)
> > +{
> > + struct pnv_phb *phb = npe->phb;
> > +
> > + /* We can only invalidate the whole cache on NPU */
> > + unsigned long val = (0x8ull << 60);
>
> Are these masks and shifts documented anywhere?
Not publicly afaik, but it would be good to add the definitions here so I'll
add the #define's for that register.
> > + if (phb->type != PNV_PHB_NPU ||
> > + !phb->ioda.tce_inval_reg ||
> > + !(npe->flags & PNV_IODA_PE_DEV))
> > + return;
>
> Should any of those ever happen, or could this be a WARN_ON() ?
Nope. WARN_ON() would be best.
> > + mb(); /* Ensure above stores are visible */
>
> What stores?
TCE invalidation requires a write to the TCE table in system memory before
invalidating the NPU TCE cache by writing values to the tce_inval_reg. The
barrier ensures that any writes to the TCE table (which occur in the
[PATCH] p1010rdb:update dts for pcie interrupt-map
p1010rdb use the irq[4:5] for inta and intb to pcie,
it is active-high, so set it.
Signed-off-by: Zhao Qiang
---
arch/powerpc/boot/dts/fsl/p1010rdb.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/p1010rdb.dtsi
b/arch/powerpc/boot/dts/fsl/p1010rdb.dtsi
index 0f0ced6..14b6295 100644
--- a/arch/powerpc/boot/dts/fsl/p1010rdb.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1010rdb.dtsi
@@ -215,3 +215,19 @@
phy-connection-type = "sgmii";
};
};
+
+&pci0 {
+ pcie@0 {
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ /*
+*irq[4:5] are active-high
+*irq[6:7] are active-low
+*/
+ 0x0 0x0 0x1 &mpic 0x4 0x2 0x0 0x0
+ 0x0 0x0 0x2 &mpic 0x5 0x2 0x0 0x0
+ 0x0 0x0 0x3 &mpic 0x6 0x1 0x0 0x0
+ 0x0 0x0 0x4 &mpic 0x7 0x1 0x0 0x0
+ >;
+ };
+};
--
2.1.0.27.g96db324
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 4/6] cxlflash: Fix to resolve cmd leak after host reset
On 15/12/15 08:07, Uma Krishnan wrote: From: Manoj Kumar After a few iterations of resetting the card, either during EEH recovery, or a host_reset the following is seen in the logs. cxlflash 0008:00: cxlflash_queuecommand: could not get a free command At every reset of the card, the commands that are outstanding are being leaked. No effort is being made to reap these commands. A few more resets later, the above error message floods the logs and the card is rendered totally unusable as no free commands are available. Iterated through the 'cmd' queue and printed out the 'free' counter and found that on each reset certain commands were in-use and stayed in-use through subsequent resets. To resolve this issue, when the card is reset, reap all the commands that are active/outstanding. Signed-off-by: Manoj N. Kumar Acked-by: Matthew R. Ochs Looks reasonable. Reviewed-by: Andrew Donnellan -- Andrew Donnellan Software Engineer, OzLabs andrew.donnel...@au1.ibm.com Australia Development Lab, Canberra +61 2 6201 8874 (work)IBM Australia Limited ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] powerpc: Enable UBSAN support
On 10/12/15 11:42, Daniel Axtens wrote: This hooks up UBSAN support for PowerPC. So far it's found some interesting cases where we don't properly sanitise input to shifts, including one in our futex handling. Nothing critical, but interesting and worth fixing. CC: Andrey Ryabinin --- This to be applied on top of next with Andrey's patches: 1) https://patchwork.kernel.org/patch/7761341/ 2) https://patchwork.kernel.org/patch/7761351/ 3) https://patchwork.kernel.org/patch/7761361/ 4) https://patchwork.kernel.org/patch/7785791/ This is RFC for a couple of reasons: - I'd like the original patches to s/ARCH_HAS_UBSAN_SANTIZE_ALL/ARCH_HAS_UBSAN_SAN*I*TIZE_ALL/ (I'm about to send an email about that) - I've only tested on LE pseries so far - I want to test on powernv, and on BE. Signed-off-by: Daniel Axtens I tested this patch as found in linux-next, along with the SANITIZE_ALL typo fix, on a big-endian BML system, with gcc 5.2.1. It successfully picked up one of the shift input issues that Daniel found, so therefore... Tested-by: Andrew Donnellan -- Andrew Donnellan Software Engineer, OzLabs andrew.donnel...@au1.ibm.com Australia Development Lab, Canberra +61 2 6201 8874 (work)IBM Australia Limited ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 3/6] cxlflash: Removed driver date print
On 15/12/15 08:06, Uma Krishnan wrote: Having a date for the driver requires it to be updated quite often. Removing the date which is not necessary. Also made use of the existing symbol to print the driver name. Signed-off-by: Uma Krishnan Reviewed-by: Andrew Donnellan -- Andrew Donnellan Software Engineer, OzLabs andrew.donnel...@au1.ibm.com Australia Development Lab, Canberra +61 2 6201 8874 (work)IBM Australia Limited ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 3/6] cxlflash: Removed driver date print
Acked-by: Matthew R. Ochs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V3] cpufreq: qoriq: Register cooling device based on device tree
On Thursday, November 26, 2015 05:21:11 PM Jia Hongtao wrote: > Register the qoriq cpufreq driver as a cooling device, based on the > thermal device tree framework. When temperature crosses the passive trip > point cpufreq is used to throttle CPUs. > > Signed-off-by: Jia Hongtao > Reviewed-by: Viresh Kumar Applied, thanks! Rafael ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [POWERPC] bootwrapper: One check less in fsl_get_immr() after error detection
On Mon, 2015-12-14 at 23:10 +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Mon, 14 Dec 2015 23:01:32 +0100 > > A status check was performed by the fsl_get_immr() function even if it > was known already that a system setting did not fit to the expectations. > > This implementation detail could be improved by an adjustment for > a jump label according to the Linux coding style convention. What is the actual problem you're trying to solve? Cluttering the code to micro-optimize an error path is not an improvement. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[POWERPC] bootwrapper: One check less in fsl_get_immr() after error detection
From: Markus Elfring
Date: Mon, 14 Dec 2015 23:01:32 +0100
A status check was performed by the fsl_get_immr() function even if it
was known already that a system setting did not fit to the expectations.
This implementation detail could be improved by an adjustment for
a jump label according to the Linux coding style convention.
Signed-off-by: Markus Elfring
---
arch/powerpc/boot/fsl-soc.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/boot/fsl-soc.c b/arch/powerpc/boot/fsl-soc.c
index b835ed6..ff1dae3 100644
--- a/arch/powerpc/boot/fsl-soc.c
+++ b/arch/powerpc/boot/fsl-soc.c
@@ -34,24 +34,24 @@ u32 *fsl_get_immr(void)
naddr = 2;
if (naddr != 1 && naddr != 2)
- goto err;
+ goto report_failure;
size = getprop(soc, "ranges", prop_buf, MAX_PROP_LEN);
if (size < 12)
- goto err;
+ goto report_failure;
if (prop_buf[0] != 0)
- goto err;
+ goto report_failure;
if (naddr == 2 && prop_buf[1] != 0)
- goto err;
+ goto report_failure;
if (!dt_xlate_addr(soc, prop_buf + naddr, 8, &ret))
ret = 0;
}
-err:
- if (!ret)
+ if (!ret) {
+report_failure:
printf("fsl_get_immr: Failed to find immr base\r\n");
-
+ }
return (u32 *)ret;
}
--
2.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] cpufreq: powernv: Redesign the presentation of throttle notification
On 12/13/2015 12:17 PM, Shilpasri G Bhat wrote:
Replace the throttling event console messages to perf trace event
"power:powernv_throttle" and throttle counter stats which are
exported in sysfs. The newly added sysfs files are as follows:
1)/sys/devices/system/node/node0/throttle_frequencies
This gives the throttle stats for each of the available frequencies.
The throttle stat of a frequency is the total number of times the max
frequency was reduced to that frequency.
# cat /sys/devices/system/node/node0/throttle_frequencies
4023000 0
399 0
3956000 1
3923000 0
389 0
3857000 2
3823000 0
379 0
3757000 2
3724000 1
369 1
...
Is this data useful? It seems like "elapsed time" at each frequency might be
more useful, if any.
2)/sys/devices/system/node/node0/throttle_reasons
This gives the stats for each of the supported throttle reasons.
This gives the total number of times the frequency was throttled due
to each of the reasons.
# cat /sys/devices/system/node/node0/throttle_reasons
No throttling 7
Power Cap 0
Processor Over Temperature 7
Power Supply Failure 0
Over Current 0
OCC Reset 0
3)/sys/devices/system/node/node0/throttle_stat
This gives the total number of throttle events occurred in turbo
range of frequencies and non-turbo(below nominal) range of
frequencies.
non-turbo should read "at or below nominal". Maybe "sub-turbo" is a better
term(?)
# cat /sys/devices/system/node/node0/throttle_stat
Turbo 7
Nominal 0
Should this read "Non-turbo" or "Sub-turbo" instead of "Nominal", since the
events could well occur when already operating below nominal.
Signed-off-by: Shilpasri G Bhat
---
drivers/cpufreq/powernv-cpufreq.c | 186 +-
include/trace/events/power.h | 22 +
2 files changed, 166 insertions(+), 42 deletions(-)
diff --git a/drivers/cpufreq/powernv-cpufreq.c
b/drivers/cpufreq/powernv-cpufreq.c
index cb50138..bdde9d6 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -28,6 +28,9 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
@@ -43,12 +46,27 @@
static struct cpufreq_frequency_table powernv_freqs[POWERNV_MAX_PSTATES+1];
static bool rebooting, throttled, occ_reset;
+static char throttle_reason[][30] = {
+ "No throttling",
+ "Power Cap",
+ "Processor Over Temperature",
+ "Power Supply Failure",
+ "Over Current",
+ "OCC Reset"
+};
I'm curious if this would be slightly more efficiently implemented as:
static const char *throttle_reason[] = { ... };
Do you need 30 characters per string for a reason?
Regardless, it should be const.
[...]
--
PC
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 6/6] cxlflash: Enable device id for future IBM CXL adapter
From: Manoj Kumar
This drop enables a future card with a device id
of 0x0600 to be recognized by the cxlflash driver.
As per the design, the Accelerator Function Unit (AFU)
for this new IBM CXL Flash Adapter retains the same
host interface as the previous generation. For the early
prototypes of the new card, the driver with this change
behaves exactly as the driver prior to this behaved with
the earlier generation card. Therefore, no card specific
programming has been added. These card specific changes
can be staged in later if needed.
Signed-off-by: Manoj N. Kumar
Acked-by: Matthew R. Ochs
---
drivers/scsi/cxlflash/main.c | 3 +++
drivers/scsi/cxlflash/main.h | 4 ++--
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/cxlflash/main.c b/drivers/scsi/cxlflash/main.c
index 30542ca..f6d90ce 100644
--- a/drivers/scsi/cxlflash/main.c
+++ b/drivers/scsi/cxlflash/main.c
@@ -2309,6 +2309,7 @@ static struct scsi_host_template driver_template = {
* Device dependent values
*/
static struct dev_dependent_vals dev_corsa_vals = { CXLFLASH_MAX_SECTORS };
+static struct dev_dependent_vals dev_flash_gt_vals = { CXLFLASH_MAX_SECTORS };
/*
* PCI device binding table
@@ -2316,6 +2317,8 @@ static struct dev_dependent_vals dev_corsa_vals = {
CXLFLASH_MAX_SECTORS };
static struct pci_device_id cxlflash_pci_table[] = {
{PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_CORSA,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, (kernel_ulong_t)&dev_corsa_vals},
+ {PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_FLASH_GT,
+PCI_ANY_ID, PCI_ANY_ID, 0, 0, (kernel_ulong_t)&dev_flash_gt_vals},
{}
};
diff --git a/drivers/scsi/cxlflash/main.h b/drivers/scsi/cxlflash/main.h
index 7e2d0e1..0faed42 100644
--- a/drivers/scsi/cxlflash/main.h
+++ b/drivers/scsi/cxlflash/main.h
@@ -23,8 +23,8 @@
#define CXLFLASH_NAME "cxlflash"
#define CXLFLASH_ADAPTER_NAME "IBM POWER CXL Flash Adapter"
-#define PCI_DEVICE_ID_IBM_CORSA0x04F0
-#define CXLFLASH_SUBS_DEV_ID 0x04F0
+#define PCI_DEVICE_ID_IBM_CORSA0x04F0
+#define PCI_DEVICE_ID_IBM_FLASH_GT 0x0600
/* Since there is only one target, make it 0 */
#define CXLFLASH_TARGET0
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 5/6] cxlflash: Resolve oops in wait_port_offline
From: Manoj Kumar
If an async error interrupt is generated, and the error requires the FC
link to be reset, it cannot be performed in the interrupt context. So
a work element is scheduled to complete the link reset in a process
context. If either an EEH event or an escalation occurs in between
when the interrupt is generated and the scheduled work is started, the
MMIO space may no longer be available. This will cause an oops in the
worker thread.
[ 606.806583] NIP kthread_data+0x28/0x40
[ 606.806633] LR wq_worker_sleeping+0x30/0x100
[ 606.806694] Call Trace:
[ 606.806721] 0x50 (unreliable)
[ 606.806796] wq_worker_sleeping+0x30/0x100
[ 606.806884] __schedule+0x69c/0x8a0
[ 606.806959] schedule+0x44/0xc0
[ 606.807034] do_exit+0x770/0xb90
[ 606.807109] die+0x300/0x460
[ 606.807185] bad_page_fault+0xd8/0x150
[ 606.807259] handle_page_fault+0x2c/0x30
[ 606.807338] wait_port_offline.constprop.12+0x60/0x130 [cxlflash]
To prevent the problem space area from being unmapped, when there is
pending work, a mapcount (using the kref mechanism) is held. The mapcount
is released only when the work is completed. The last reference release
is tied to the unmapping service.
Signed-off-by: Manoj N. Kumar
Acked-by: Matthew R. Ochs
---
drivers/scsi/cxlflash/common.h | 2 ++
drivers/scsi/cxlflash/main.c | 27 ---
2 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/cxlflash/common.h b/drivers/scsi/cxlflash/common.h
index c11cd19..5ada926 100644
--- a/drivers/scsi/cxlflash/common.h
+++ b/drivers/scsi/cxlflash/common.h
@@ -165,6 +165,8 @@ struct afu {
struct sisl_host_map __iomem *host_map; /* MC host map */
struct sisl_ctrl_map __iomem *ctrl_map; /* MC control map */
+ struct kref mapcount;
+
ctx_hndl_t ctx_hndl;/* master's context handle */
u64 *hrrq_start;
u64 *hrrq_end;
diff --git a/drivers/scsi/cxlflash/main.c b/drivers/scsi/cxlflash/main.c
index ac39856..30542ca 100644
--- a/drivers/scsi/cxlflash/main.c
+++ b/drivers/scsi/cxlflash/main.c
@@ -368,6 +368,7 @@ out:
no_room:
afu->read_room = true;
+ kref_get(&cfg->afu->mapcount);
schedule_work(&cfg->work_q);
rc = SCSI_MLQUEUE_HOST_BUSY;
goto out;
@@ -473,6 +474,16 @@ out:
return rc;
}
+static void afu_unmap(struct kref *ref)
+{
+ struct afu *afu = container_of(ref, struct afu, mapcount);
+
+ if (likely(afu->afu_map)) {
+ cxl_psa_unmap((void __iomem *)afu->afu_map);
+ afu->afu_map = NULL;
+ }
+}
+
/**
* cxlflash_driver_info() - information handler for this host driver
* @host: SCSI host associated with device.
@@ -503,6 +514,7 @@ static int cxlflash_queuecommand(struct Scsi_Host *host,
struct scsi_cmnd *scp)
ulong lock_flags;
short lflag = 0;
int rc = 0;
+ int kref_got = 0;
dev_dbg_ratelimited(dev, "%s: (scp=%p) %d/%d/%d/%llu "
"cdb=(%08X-%08X-%08X-%08X)\n",
@@ -547,6 +559,9 @@ static int cxlflash_queuecommand(struct Scsi_Host *host,
struct scsi_cmnd *scp)
goto out;
}
+ kref_get(&cfg->afu->mapcount);
+ kref_got = 1;
+
cmd->rcb.ctx_id = afu->ctx_hndl;
cmd->rcb.port_sel = port_sel;
cmd->rcb.lun_id = lun_to_lunid(scp->device->lun);
@@ -587,6 +602,8 @@ static int cxlflash_queuecommand(struct Scsi_Host *host,
struct scsi_cmnd *scp)
}
out:
+ if (kref_got)
+ kref_put(&afu->mapcount, afu_unmap);
pr_devel("%s: returning rc=%d\n", __func__, rc);
return rc;
}
@@ -661,6 +678,7 @@ static void stop_afu(struct cxlflash_cfg *cfg)
cxl_psa_unmap((void __iomem *)afu->afu_map);
afu->afu_map = NULL;
}
+ kref_put(&afu->mapcount, afu_unmap);
}
}
@@ -746,8 +764,8 @@ static void cxlflash_remove(struct pci_dev *pdev)
scsi_remove_host(cfg->host);
/* fall through */
case INIT_STATE_AFU:
- term_afu(cfg);
cancel_work_sync(&cfg->work_q);
+ term_afu(cfg);
case INIT_STATE_PCI:
pci_release_regions(cfg->dev);
pci_disable_device(pdev);
@@ -1331,6 +1349,7 @@ static irqreturn_t cxlflash_async_err_irq(int irq, void
*data)
__func__, port);
cfg->lr_state = LINK_RESET_REQUIRED;
cfg->lr_port = port;
+ kref_get(&cfg->afu->mapcount);
schedule_work(&cfg->work_q);
}
@@ -1351,6 +1370,7 @@ static irqreturn_t cxlflash_async_err_irq(int irq, void
*data)
if (info->action & SCAN_HOST) {
atomic_inc(&cfg->scan_host_needed);
+ kref_get(&cfg->afu->mapcount);
schedule_work(&cfg
[PATCH v2 4/6] cxlflash: Fix to resolve cmd leak after host reset
From: Manoj Kumar
After a few iterations of resetting the card, either during EEH
recovery, or a host_reset the following is seen in the logs.
cxlflash 0008:00: cxlflash_queuecommand: could not get a free command
At every reset of the card, the commands that are outstanding are
being leaked. No effort is being made to reap these commands. A few
more resets later, the above error message floods the logs and the
card is rendered totally unusable as no free commands are available.
Iterated through the 'cmd' queue and printed out the 'free' counter
and found that on each reset certain commands were in-use and
stayed in-use through subsequent resets.
To resolve this issue, when the card is reset, reap all the commands
that are active/outstanding.
Signed-off-by: Manoj N. Kumar
Acked-by: Matthew R. Ochs
---
drivers/scsi/cxlflash/main.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/cxlflash/main.c b/drivers/scsi/cxlflash/main.c
index 35a3202..ac39856 100644
--- a/drivers/scsi/cxlflash/main.c
+++ b/drivers/scsi/cxlflash/main.c
@@ -632,15 +632,30 @@ static void free_mem(struct cxlflash_cfg *cfg)
* @cfg: Internal structure associated with the host.
*
* Safe to call with AFU in a partially allocated/initialized state.
+ *
+ * Cleans up all state associated with the command queue, and unmaps
+ * the MMIO space.
+ *
+ * - complete() will take care of commands we initiated (they'll be checked
+ * in as part of the cleanup that occurs after the completion)
+ *
+ * - cmd_checkin() will take care of entries that we did not initiate and that
+ * have not (and will not) complete because they are sitting on a [now stale]
+ * hardware queue
*/
static void stop_afu(struct cxlflash_cfg *cfg)
{
int i;
struct afu *afu = cfg->afu;
+ struct afu_cmd *cmd;
if (likely(afu)) {
- for (i = 0; i < CXLFLASH_NUM_CMDS; i++)
- complete(&afu->cmd[i].cevent);
+ for (i = 0; i < CXLFLASH_NUM_CMDS; i++) {
+ cmd = &afu->cmd[i];
+ complete(&cmd->cevent);
+ if (!atomic_read(&cmd->free))
+ cmd_checkin(cmd);
+ }
if (likely(afu->afu_map)) {
cxl_psa_unmap((void __iomem *)afu->afu_map);
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 3/6] cxlflash: Removed driver date print
Having a date for the driver requires it to be updated quite
often. Removing the date which is not necessary. Also made
use of the existing symbol to print the driver name.
Signed-off-by: Uma Krishnan
---
drivers/scsi/cxlflash/main.c | 3 +--
drivers/scsi/cxlflash/main.h | 1 -
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/scsi/cxlflash/main.c b/drivers/scsi/cxlflash/main.c
index 09fe252..35a3202 100644
--- a/drivers/scsi/cxlflash/main.c
+++ b/drivers/scsi/cxlflash/main.c
@@ -2585,8 +2585,7 @@ static struct pci_driver cxlflash_driver = {
*/
static int __init init_cxlflash(void)
{
- pr_info("%s: IBM Power CXL Flash Adapter: %s\n",
- __func__, CXLFLASH_DRIVER_DATE);
+ pr_info("%s: %s\n", __func__, CXLFLASH_ADAPTER_NAME);
cxlflash_list_init();
diff --git a/drivers/scsi/cxlflash/main.h b/drivers/scsi/cxlflash/main.h
index 6032456..7e2d0e1 100644
--- a/drivers/scsi/cxlflash/main.h
+++ b/drivers/scsi/cxlflash/main.h
@@ -22,7 +22,6 @@
#define CXLFLASH_NAME "cxlflash"
#define CXLFLASH_ADAPTER_NAME "IBM POWER CXL Flash Adapter"
-#define CXLFLASH_DRIVER_DATE "(August 13, 2015)"
#define PCI_DEVICE_ID_IBM_CORSA0x04F0
#define CXLFLASH_SUBS_DEV_ID 0x04F0
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 2/6] cxlflash: Fix to avoid virtual LUN failover failure
From: "Matthew R. Ochs"
Applications which use virtual LUN's that are backed by a physical LUN
over both adapter ports may experience an I/O failure in the event of
a link loss (e.g. cable pull).
Virtual LUNs may be accessed through one or both ports of the adapter.
This access is encoded in the translation entries that comprise the
virtual LUN and used by the AFU for load-balancing I/O and handling
failover scenarios. In a link loss scenario, even though the AFU is
able to maintain connectivity to the LUN, it is up to the application
to retry the failed I/O. When applications are unaware of the virtual
LUN's underlying topology, they are unable to make a sound decision of
when to retry an I/O and therefore are forced to make their reaction to
a failed I/O absolute. The result is either a failure to retry I/O or
increased latency for scenarios where a retry is pointless.
To remedy this scenario, provide feedback back to the application on
virtual LUN creation as to which ports the LUN may be accessed. LUN's
spanning both ports are candidates for a retry in a presence of an I/O
failure.
Signed-off-by: Matthew R. Ochs
Acked-by: Manoj Kumar
---
drivers/scsi/cxlflash/vlun.c | 2 ++
include/uapi/scsi/cxlflash_ioctl.h | 10 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/scsi/cxlflash/vlun.c b/drivers/scsi/cxlflash/vlun.c
index a53f583..50f8e93 100644
--- a/drivers/scsi/cxlflash/vlun.c
+++ b/drivers/scsi/cxlflash/vlun.c
@@ -1008,6 +1008,8 @@ int cxlflash_disk_virtual_open(struct scsi_device *sdev,
void *arg)
virt->last_lba = last_lba;
virt->rsrc_handle = rsrc_handle;
+ if (lli->port_sel == BOTH_PORTS)
+ virt->hdr.return_flags |= DK_CXLFLASH_ALL_PORTS_ACTIVE;
out:
if (likely(ctxi))
put_context(ctxi);
diff --git a/include/uapi/scsi/cxlflash_ioctl.h
b/include/uapi/scsi/cxlflash_ioctl.h
index 831351b..2302f3c 100644
--- a/include/uapi/scsi/cxlflash_ioctl.h
+++ b/include/uapi/scsi/cxlflash_ioctl.h
@@ -31,6 +31,16 @@ struct dk_cxlflash_hdr {
};
/*
+ * Return flag definitions available to all ioctls
+ *
+ * Similar to the input flags, these are grown from the bottom-up with the
+ * intention that ioctl-specific return flag definitions would grow from the
+ * top-down, allowing the two sets to co-exist. While not required/enforced
+ * at this time, this provides future flexibility.
+ */
+#define DK_CXLFLASH_ALL_PORTS_ACTIVE 0x0001ULL
+
+/*
* Notes:
* -
* The 'context_id' field of all ioctl structures contains the context
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 0/6] cxlflash: Miscellaneous fixes and updates
This patch set contains miscellaneous fixes and adds support for a future IBM CXL adapter. This series is intended for 4.5 and is bisectable. Please reference the changelog below for details on what has been altered from previous versions of this patch set. v2 Changes: - Incorporate comments from Daniel Axtens - Incorporate comments from Andrew Donnellan - Removed driver date and simplified driver load print - Clarified driver behavior for the future adapter Manoj Kumar (4): cxlflash: Fix to escalate LINK_RESET also on port 1 cxlflash: Fix to resolve cmd leak after host reset cxlflash: Resolve oops in wait_port_offline cxlflash: Enable device id for future IBM CXL adapter Matthew R. Ochs (1): cxlflash: Fix to avoid virtual LUN failover failure Uma Krishnan (1): cxlflash: Removed driver date print drivers/scsi/cxlflash/common.h | 2 ++ drivers/scsi/cxlflash/main.c | 54 -- drivers/scsi/cxlflash/main.h | 5 ++-- drivers/scsi/cxlflash/vlun.c | 2 ++ include/uapi/scsi/cxlflash_ioctl.h | 10 +++ 5 files changed, 62 insertions(+), 11 deletions(-) -- 2.1.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 1/6] cxlflash: Fix to escalate LINK_RESET also on port 1
From: Manoj Kumar
The original fix to escalate a 'login timed out' error
to a LINK_RESET was only made for one of the two ports
on the card. This fix resolves the same issue for
the second port (port 1).
Signed-off-by: Manoj N. Kumar
Acked-by: Matthew R. Ochs
---
drivers/scsi/cxlflash/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/cxlflash/main.c b/drivers/scsi/cxlflash/main.c
index 1e5bf0c..09fe252 100644
--- a/drivers/scsi/cxlflash/main.c
+++ b/drivers/scsi/cxlflash/main.c
@@ -1108,7 +1108,7 @@ static const struct asyc_intr_info ainfo[] = {
{SISL_ASTATUS_FC1_OTHER, "other error", 1, CLR_FC_ERROR | LINK_RESET},
{SISL_ASTATUS_FC1_LOGO, "target initiated LOGO", 1, 0},
{SISL_ASTATUS_FC1_CRC_T, "CRC threshold exceeded", 1, LINK_RESET},
- {SISL_ASTATUS_FC1_LOGI_R, "login timed out, retrying", 1, 0},
+ {SISL_ASTATUS_FC1_LOGI_R, "login timed out, retrying", 1, LINK_RESET},
{SISL_ASTATUS_FC1_LOGI_F, "login failed", 1, CLR_FC_ERROR},
{SISL_ASTATUS_FC1_LOGI_S, "login succeeded", 1, SCAN_HOST},
{SISL_ASTATUS_FC1_LINK_DN, "link down", 1, 0},
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 0/6] cxlflash: Miscellaneous fixes and updates
This patch set contains miscellaneous fixes and adds support for a future IBM CXL adapter. This series is intended for 4.5 and is bisectable. Please reference the changelog below for details on what has been altered from previous versions of this patch set. v2 Changes: - Incorporate comments from Daniel Axtens - Incorporate comments from Andrew Donnellan - Removed driver date and simplified driver load print - Clarified driver behavior for the future adapter Manoj Kumar (4): cxlflash: Fix to escalate LINK_RESET also on port 1 cxlflash: Fix to resolve cmd leak after host reset cxlflash: Resolve oops in wait_port_offline cxlflash: Enable device id for future IBM CXL adapter Matthew R. Ochs (1): cxlflash: Fix to avoid virtual LUN failover failure Uma Krishnan (1): cxlflash: Removed driver date print drivers/scsi/cxlflash/common.h | 2 ++ drivers/scsi/cxlflash/main.c | 54 -- drivers/scsi/cxlflash/main.h | 5 ++-- drivers/scsi/cxlflash/vlun.c | 2 ++ include/uapi/scsi/cxlflash_ioctl.h | 10 +++ 5 files changed, 62 insertions(+), 11 deletions(-) -- 2.1.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 0/6] cxlflash: Miscellaneous fixes and updates
This patch set contains miscellaneous fixes and adds support for a future IBM CXL adapter. This series is intended for 4.5 and is bisectable. Please reference the changelog below for details on what has been altered from previous versions of this patch set. v2 Changes: - Incorporate comments from Daniel Axtens - Incorporate comments from Andrew Donnellan - Removed driver date and simplified driver load print - Clarified driver behavior for the future adapter Manoj Kumar (4): cxlflash: Fix to escalate LINK_RESET also on port 1 cxlflash: Fix to resolve cmd leak after host reset cxlflash: Resolve oops in wait_port_offline cxlflash: Enable device id for future IBM CXL adapter Matthew R. Ochs (1): cxlflash: Fix to avoid virtual LUN failover failure Uma Krishnan (1): cxlflash: Removed driver date print drivers/scsi/cxlflash/common.h | 2 ++ drivers/scsi/cxlflash/main.c | 54 -- drivers/scsi/cxlflash/main.h | 5 ++-- drivers/scsi/cxlflash/vlun.c | 2 ++ include/uapi/scsi/cxlflash_ioctl.h | 10 +++ 5 files changed, 62 insertions(+), 11 deletions(-) -- 2.1.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 2/2] powerpc: tracing: don't trace hcalls on offline CPUs
./drmgr -c cpu -a -r gives the following warning: [ 2327.035563] RCU used illegally from offline CPU! rcu_scheduler_active = 1, debug_locks = 1 [ 2327.035564] no locks held by swapper/12/0. [ 2327.035565] stack backtrace: [ 2327.035567] CPU: 12 PID: 0 Comm: swapper/12 Tainted: G S 4.3.0-rc3-00060-g353169a #5 [ 2327.035568] Call Trace: [ 2327.035573] [c001d62578e0] [c08977fc] .dump_stack+0x98/0xd4 (unreliable) [ 2327.035577] [c001d6257960] [c0109bd8] .lockdep_rcu_suspicious+0x108/0x170 [ 2327.035580] [c001d62579f0] [c006a1d0] .__trace_hcall_exit+0x2b0/0x2c0 [ 2327.035584] [c001d6257ab0] [c006a2e8] plpar_hcall_norets_trace+0x70/0x8c [ 2327.035588] [c001d6257b20] [c0067a14] .icp_hv_set_cpu_priority+0x54/0xc0 [ 2327.035592] [c001d6257ba0] [c0066c5c] .xics_teardown_cpu+0x5c/0xa0 [ 2327.035595] [c001d6257c20] [c00747ac] .pseries_mach_cpu_die+0x6c/0x320 [ 2327.035598] [c001d6257cd0] [c00439cc] .cpu_die+0x3c/0x60 [ 2327.035602] [c001d6257d40] [c00183d8] .arch_cpu_idle_dead+0x28/0x40 [ 2327.035606] [c001d6257db0] [c00ff1dc] .cpu_startup_entry+0x4fc/0x560 [ 2327.035610] [c001d6257ed0] [c0043728] .start_secondary+0x328/0x360 [ 2327.035614] [c001d6257f90] [c0008a6c] start_secondary_prolog+0x10/0x14 [ 2327.035620] cpu 12 (hwid 12) Ready to die... [ 2327.144463] cpu 13 (hwid 13) Ready to die... [ 2327.294180] cpu 14 (hwid 14) Ready to die... [ 2327.403599] cpu 15 (hwid 15) Ready to die... Make the hypervisor tracepoints conditional by using TRACE_EVENT_FN_COND Signed-off-by: Denis Kirjanov v2 changes: - Use raw_smp_processor_id as suggested by BenH since since hcalls can be called from preemptable sections v3 changes: - Fix the subject line --- arch/powerpc/include/asm/trace.h | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/include/asm/trace.h b/arch/powerpc/include/asm/trace.h index 8e86b48..32e36b1 100644 --- a/arch/powerpc/include/asm/trace.h +++ b/arch/powerpc/include/asm/trace.h @@ -57,12 +57,14 @@ DEFINE_EVENT(ppc64_interrupt_class, timer_interrupt_exit, extern void hcall_tracepoint_regfunc(void); extern void hcall_tracepoint_unregfunc(void); -TRACE_EVENT_FN(hcall_entry, +TRACE_EVENT_FN_COND(hcall_entry, TP_PROTO(unsigned long opcode, unsigned long *args), TP_ARGS(opcode, args), + TP_CONDITION(cpu_online(raw_smp_processor_id())), + TP_STRUCT__entry( __field(unsigned long, opcode) ), @@ -76,13 +78,15 @@ TRACE_EVENT_FN(hcall_entry, hcall_tracepoint_regfunc, hcall_tracepoint_unregfunc ); -TRACE_EVENT_FN(hcall_exit, +TRACE_EVENT_FN_COND(hcall_exit, TP_PROTO(unsigned long opcode, unsigned long retval, unsigned long *retbuf), TP_ARGS(opcode, retval, retbuf), + TP_CONDITION(cpu_online(raw_smp_processor_id())), + TP_STRUCT__entry( __field(unsigned long, opcode) __field(unsigned long, retval) -- 2.4.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 1/2] tracing: introduce TRACE_EVENT_FN_COND macro
TRACE_EVENT_FN can't be used in some circumstances like invoking trace functions from offlined CPU due to RCU usage. This patch adds the TRACE_EVENT_FN_COND macro to make such trace points conditional. Signed-off-by: Denis Kirjanov --- include/linux/tracepoint.h | 4 include/trace/define_trace.h | 6 ++ include/trace/trace_events.h | 6 ++ 3 files changed, 16 insertions(+) diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h index 696a339c..45b3fcf 100644 --- a/include/linux/tracepoint.h +++ b/include/linux/tracepoint.h @@ -493,6 +493,10 @@ extern void syscall_unregfunc(void); #define TRACE_EVENT_FN(name, proto, args, struct, \ assign, print, reg, unreg) \ DECLARE_TRACE(name, PARAMS(proto), PARAMS(args)) +#define TRACE_EVENT_FN_COND(name, proto, args, cond, struct, \ + assign, print, reg, unreg) \ + DECLARE_TRACE_CONDITION(name, PARAMS(proto),\ + PARAMS(args), PARAMS(cond)) #define TRACE_EVENT_CONDITION(name, proto, args, cond, \ struct, assign, print)\ DECLARE_TRACE_CONDITION(name, PARAMS(proto),\ diff --git a/include/trace/define_trace.h b/include/trace/define_trace.h index 2d8639e..6e3945f 100644 --- a/include/trace/define_trace.h +++ b/include/trace/define_trace.h @@ -40,6 +40,11 @@ assign, print, reg, unreg) \ DEFINE_TRACE_FN(name, reg, unreg) +#undef TRACE_EVENT_FN_COND +#define TRACE_EVENT_FN_COND(name, proto, args, cond, tstruct, \ + assign, print, reg, unreg) \ + DEFINE_TRACE_FN(name, reg, unreg) + #undef DEFINE_EVENT #define DEFINE_EVENT(template, name, proto, args) \ DEFINE_TRACE(name) @@ -93,6 +98,7 @@ #undef TRACE_EVENT #undef TRACE_EVENT_FN +#undef TRACE_EVENT_FN_COND #undef TRACE_EVENT_CONDITION #undef DECLARE_EVENT_CLASS #undef DEFINE_EVENT diff --git a/include/trace/trace_events.h b/include/trace/trace_events.h index de996cf..170c93b 100644 --- a/include/trace/trace_events.h +++ b/include/trace/trace_events.h @@ -123,6 +123,12 @@ TRACE_MAKE_SYSTEM_STR(); TRACE_EVENT(name, PARAMS(proto), PARAMS(args), \ PARAMS(tstruct), PARAMS(assign), PARAMS(print)) \ +#undef TRACE_EVENT_FN_COND +#define TRACE_EVENT_FN_COND(name, proto, args, cond, tstruct, \ + assign, print, reg, unreg) \ + TRACE_EVENT_CONDITION(name, PARAMS(proto), PARAMS(args), PARAMS(cond), \ + PARAMS(tstruct), PARAMS(assign), PARAMS(print)) \ + #undef TRACE_EVENT_FLAGS #define TRACE_EVENT_FLAGS(name, value) \ __TRACE_EVENT_FLAGS(name, value) -- 2.4.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] ./drmgr -c cpu -a -r gives the following warning:
On 12/14/15, Denis Kirjanov wrote: > [ 2327.035563] > RCU used illegally from offline CPU! > rcu_scheduler_active = 1, debug_locks = 1 > [ 2327.035564] no locks held by swapper/12/0. > [ 2327.035565] > stack backtrace: > [ 2327.035567] CPU: 12 PID: 0 Comm: swapper/12 Tainted: G S > 4.3.0-rc3-00060-g353169a #5 > [ 2327.035568] Call Trace: > [ 2327.035573] [c001d62578e0] [c08977fc] .dump_stack+0x98/0xd4 > (unreliable) > [ 2327.035577] [c001d6257960] [c0109bd8] > .lockdep_rcu_suspicious+0x108/0x170 > [ 2327.035580] [c001d62579f0] [c006a1d0] > .__trace_hcall_exit+0x2b0/0x2c0 > [ 2327.035584] [c001d6257ab0] [c006a2e8] > plpar_hcall_norets_trace+0x70/0x8c > [ 2327.035588] [c001d6257b20] [c0067a14] > .icp_hv_set_cpu_priority+0x54/0xc0 > [ 2327.035592] [c001d6257ba0] [c0066c5c] > .xics_teardown_cpu+0x5c/0xa0 > [ 2327.035595] [c001d6257c20] [c00747ac] > .pseries_mach_cpu_die+0x6c/0x320 > [ 2327.035598] [c001d6257cd0] [c00439cc] .cpu_die+0x3c/0x60 > [ 2327.035602] [c001d6257d40] [c00183d8] > .arch_cpu_idle_dead+0x28/0x40 > [ 2327.035606] [c001d6257db0] [c00ff1dc] > .cpu_startup_entry+0x4fc/0x560 > [ 2327.035610] [c001d6257ed0] [c0043728] > .start_secondary+0x328/0x360 > [ 2327.035614] [c001d6257f90] [c0008a6c] > start_secondary_prolog+0x10/0x14 > [ 2327.035620] cpu 12 (hwid 12) Ready to die... > [ 2327.144463] cpu 13 (hwid 13) Ready to die... > [ 2327.294180] cpu 14 (hwid 14) Ready to die... > [ 2327.403599] cpu 15 (hwid 15) Ready to die... > > Make the hypervisor tracepoints conditional > by using TRACE_EVENT_FN_COND > > Signed-off-by: Denis Kirjanov Please ignore this patch with the broken subject > > v2 changes: > - Use raw_smp_processor_id as suggested by BenH > since since hcalls can be called from preemptable sections > --- > arch/powerpc/include/asm/trace.h | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/arch/powerpc/include/asm/trace.h > b/arch/powerpc/include/asm/trace.h > index 8e86b48..32e36b1 100644 > --- a/arch/powerpc/include/asm/trace.h > +++ b/arch/powerpc/include/asm/trace.h > @@ -57,12 +57,14 @@ DEFINE_EVENT(ppc64_interrupt_class, > timer_interrupt_exit, > extern void hcall_tracepoint_regfunc(void); > extern void hcall_tracepoint_unregfunc(void); > > -TRACE_EVENT_FN(hcall_entry, > +TRACE_EVENT_FN_COND(hcall_entry, > > TP_PROTO(unsigned long opcode, unsigned long *args), > > TP_ARGS(opcode, args), > > + TP_CONDITION(cpu_online(raw_smp_processor_id())), > + > TP_STRUCT__entry( > __field(unsigned long, opcode) > ), > @@ -76,13 +78,15 @@ TRACE_EVENT_FN(hcall_entry, > hcall_tracepoint_regfunc, hcall_tracepoint_unregfunc > ); > > -TRACE_EVENT_FN(hcall_exit, > +TRACE_EVENT_FN_COND(hcall_exit, > > TP_PROTO(unsigned long opcode, unsigned long retval, > unsigned long *retbuf), > > TP_ARGS(opcode, retval, retbuf), > > + TP_CONDITION(cpu_online(raw_smp_processor_id())), > + > TP_STRUCT__entry( > __field(unsigned long, opcode) > __field(unsigned long, retval) > -- > 2.4.0 > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 1/2] tracing: introduce TRACE_EVENT_FN_COND macro
TRACE_EVENT_FN can't be used in some circumstances like invoking trace functions from offlined CPU due to RCU usage. This patch adds the TRACE_EVENT_FN_COND macro to make such trace points conditional. Signed-off-by: Denis Kirjanov --- include/linux/tracepoint.h | 4 include/trace/define_trace.h | 6 ++ include/trace/trace_events.h | 6 ++ 3 files changed, 16 insertions(+) diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h index 696a339c..45b3fcf 100644 --- a/include/linux/tracepoint.h +++ b/include/linux/tracepoint.h @@ -493,6 +493,10 @@ extern void syscall_unregfunc(void); #define TRACE_EVENT_FN(name, proto, args, struct, \ assign, print, reg, unreg) \ DECLARE_TRACE(name, PARAMS(proto), PARAMS(args)) +#define TRACE_EVENT_FN_COND(name, proto, args, cond, struct, \ + assign, print, reg, unreg) \ + DECLARE_TRACE_CONDITION(name, PARAMS(proto),\ + PARAMS(args), PARAMS(cond)) #define TRACE_EVENT_CONDITION(name, proto, args, cond, \ struct, assign, print)\ DECLARE_TRACE_CONDITION(name, PARAMS(proto),\ diff --git a/include/trace/define_trace.h b/include/trace/define_trace.h index 2d8639e..6e3945f 100644 --- a/include/trace/define_trace.h +++ b/include/trace/define_trace.h @@ -40,6 +40,11 @@ assign, print, reg, unreg) \ DEFINE_TRACE_FN(name, reg, unreg) +#undef TRACE_EVENT_FN_COND +#define TRACE_EVENT_FN_COND(name, proto, args, cond, tstruct, \ + assign, print, reg, unreg) \ + DEFINE_TRACE_FN(name, reg, unreg) + #undef DEFINE_EVENT #define DEFINE_EVENT(template, name, proto, args) \ DEFINE_TRACE(name) @@ -93,6 +98,7 @@ #undef TRACE_EVENT #undef TRACE_EVENT_FN +#undef TRACE_EVENT_FN_COND #undef TRACE_EVENT_CONDITION #undef DECLARE_EVENT_CLASS #undef DEFINE_EVENT diff --git a/include/trace/trace_events.h b/include/trace/trace_events.h index de996cf..170c93b 100644 --- a/include/trace/trace_events.h +++ b/include/trace/trace_events.h @@ -123,6 +123,12 @@ TRACE_MAKE_SYSTEM_STR(); TRACE_EVENT(name, PARAMS(proto), PARAMS(args), \ PARAMS(tstruct), PARAMS(assign), PARAMS(print)) \ +#undef TRACE_EVENT_FN_COND +#define TRACE_EVENT_FN_COND(name, proto, args, cond, tstruct, \ + assign, print, reg, unreg) \ + TRACE_EVENT_CONDITION(name, PARAMS(proto), PARAMS(args), PARAMS(cond), \ + PARAMS(tstruct), PARAMS(assign), PARAMS(print)) \ + #undef TRACE_EVENT_FLAGS #define TRACE_EVENT_FLAGS(name, value) \ __TRACE_EVENT_FLAGS(name, value) -- 2.4.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 2/2] ./drmgr -c cpu -a -r gives the following warning:
[ 2327.035563] RCU used illegally from offline CPU! rcu_scheduler_active = 1, debug_locks = 1 [ 2327.035564] no locks held by swapper/12/0. [ 2327.035565] stack backtrace: [ 2327.035567] CPU: 12 PID: 0 Comm: swapper/12 Tainted: G S 4.3.0-rc3-00060-g353169a #5 [ 2327.035568] Call Trace: [ 2327.035573] [c001d62578e0] [c08977fc] .dump_stack+0x98/0xd4 (unreliable) [ 2327.035577] [c001d6257960] [c0109bd8] .lockdep_rcu_suspicious+0x108/0x170 [ 2327.035580] [c001d62579f0] [c006a1d0] .__trace_hcall_exit+0x2b0/0x2c0 [ 2327.035584] [c001d6257ab0] [c006a2e8] plpar_hcall_norets_trace+0x70/0x8c [ 2327.035588] [c001d6257b20] [c0067a14] .icp_hv_set_cpu_priority+0x54/0xc0 [ 2327.035592] [c001d6257ba0] [c0066c5c] .xics_teardown_cpu+0x5c/0xa0 [ 2327.035595] [c001d6257c20] [c00747ac] .pseries_mach_cpu_die+0x6c/0x320 [ 2327.035598] [c001d6257cd0] [c00439cc] .cpu_die+0x3c/0x60 [ 2327.035602] [c001d6257d40] [c00183d8] .arch_cpu_idle_dead+0x28/0x40 [ 2327.035606] [c001d6257db0] [c00ff1dc] .cpu_startup_entry+0x4fc/0x560 [ 2327.035610] [c001d6257ed0] [c0043728] .start_secondary+0x328/0x360 [ 2327.035614] [c001d6257f90] [c0008a6c] start_secondary_prolog+0x10/0x14 [ 2327.035620] cpu 12 (hwid 12) Ready to die... [ 2327.144463] cpu 13 (hwid 13) Ready to die... [ 2327.294180] cpu 14 (hwid 14) Ready to die... [ 2327.403599] cpu 15 (hwid 15) Ready to die... Make the hypervisor tracepoints conditional by using TRACE_EVENT_FN_COND Signed-off-by: Denis Kirjanov v2 changes: - Use raw_smp_processor_id as suggested by BenH since since hcalls can be called from preemptable sections --- arch/powerpc/include/asm/trace.h | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/include/asm/trace.h b/arch/powerpc/include/asm/trace.h index 8e86b48..32e36b1 100644 --- a/arch/powerpc/include/asm/trace.h +++ b/arch/powerpc/include/asm/trace.h @@ -57,12 +57,14 @@ DEFINE_EVENT(ppc64_interrupt_class, timer_interrupt_exit, extern void hcall_tracepoint_regfunc(void); extern void hcall_tracepoint_unregfunc(void); -TRACE_EVENT_FN(hcall_entry, +TRACE_EVENT_FN_COND(hcall_entry, TP_PROTO(unsigned long opcode, unsigned long *args), TP_ARGS(opcode, args), + TP_CONDITION(cpu_online(raw_smp_processor_id())), + TP_STRUCT__entry( __field(unsigned long, opcode) ), @@ -76,13 +78,15 @@ TRACE_EVENT_FN(hcall_entry, hcall_tracepoint_regfunc, hcall_tracepoint_unregfunc ); -TRACE_EVENT_FN(hcall_exit, +TRACE_EVENT_FN_COND(hcall_exit, TP_PROTO(unsigned long opcode, unsigned long retval, unsigned long *retbuf), TP_ARGS(opcode, retval, retbuf), + TP_CONDITION(cpu_online(raw_smp_processor_id())), + TP_STRUCT__entry( __field(unsigned long, opcode) __field(unsigned long, retval) -- 2.4.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/6] cxlflash: Updated date of the driver
On 12/10/2015 6:35 PM, Daniel Axtens wrote: Hi Uma, It looks like CXLFLASH_DRIVER_DATE is only used once, on init, and it's just printed. Is it necessary? It looks like having it will require sending a patch to update it quite often. Hi Daniel, Valid point. I will pull this out from the code. This should be included in the second version of the patch series. Thanks, Uma Krishnan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH net-next v2] Driver for IBM System i/p VNIC protocol
On 12/11/2015 06:53 PM, David Miller wrote:
> From: Thomas Falcon
> Date: Tue, 8 Dec 2015 11:52:19 -0600
>
>> +static long h_reg_sub_crq(unsigned long unit_address, unsigned long token,
>> + unsigned long length, unsigned long *number,
>> + unsigned long *irq)
>> +{
>> +long rc;
>> +unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
> Please declare local variables from longest to shortest line, otherwise
> known as "reverse christmas tree" order.
>
> Audit this in your entire driver.
>
>> +pool->rx_buff = kcalloc(pool->size, sizeof(struct ibmvnic_rx_buff),
>> +GFP_KERNEL);
> Allocation failures not checked until much later in this function, where
> several other resources have been allocated meanwhile. That doesn't
> make any sense at all.
>
>> +adapter->closing = 1;
> Please use type 'bool' and values 'true' and 'false' for boolean
> values.
>
> Audit this in your entire driver.
>
>> +if (ip_hdr(skb)->version == 4)
>> +tx_crq.v1.flags1 |= IBMVNIC_TX_PROT_IPV4;
>> +else if (ip_hdr(skb)->version == 6)
>> +tx_crq.v1.flags1 |= IBMVNIC_TX_PROT_IPV6;
>> +
> You cannot dereference the protocol header of the SKB without
> first checking the skb->protocol value, otherwise you're looking
> at garbage.
>
>> +static int ibmvnic_set_mac(struct net_device *netdev, void *p)
>> +{
>> +struct ibmvnic_adapter *adapter = netdev_priv(netdev);
>> +struct sockaddr *addr = p;
>> +union ibmvnic_crq crq;
>> +
>> +if (!is_valid_ether_addr(addr->sa_data))
>> +return -EADDRNOTAVAIL;
>> +
>> +memset(&crq, 0, sizeof(crq));
>> +crq.change_mac_addr.first = IBMVNIC_CRQ_CMD;
>> +crq.change_mac_addr.cmd = CHANGE_MAC_ADDR;
>> +ether_addr_copy(&crq.change_mac_addr.mac_addr[0], addr->sa_data);
>> +ibmvnic_send_crq(adapter, &crq);
>> +
>> +return 0;
>> +}
> You are responsible for copying the new MAC address into dev->dev_addr
> on success.
We do this in another function (handle_change_mac_rsp), which handles the
response from firmware indicating whether the CHANGE_MAC_ADDR command was
successful. Is this acceptable?
Thank you for your review comments and your time.
>
>> +static int ibmvnic_mii_ioctl(struct net_device *netdev, struct ifreq *ifr,
>> + int cmd)
>> +{
> ...
>> +return 0;
>> +}
>> +
>> +static int ibmvnic_ioctl(struct net_device *netdev, struct ifreq *ifr, int
>> cmd)
>> +{
>> +switch (cmd) {
>> +case SIOCGMIIPHY:
>> +case SIOCGMIIREG:
>> +case SIOCSMIIREG:
>> +return ibmvnic_mii_ioctl(netdev, ifr, cmd);
>> +default:
>> +return -EOPNOTSUPP;
>> +}
>> +}
> This really doesn't make any sense. Please just delete this. You
> don't support MII reads or writes because they logically don't make
> sense on this device.
>
>> +static struct net_device_stats *ibmvnic_get_stats(struct net_device *dev)
>> +{
>> +struct ibmvnic_adapter *adapter = netdev_priv(dev);
>> +
>> +/* only return the current stats */
>> +return &adapter->net_stats;
>> +}
> The default method does this for you as long as you properly use
> net_device's embedded stats, therefore you don't need to provide this
> at all.
>
> That's all I have any energy for, and as you can see nobody else wants
> to even try to review this driver.
>
> It's going to take a lot of respins and time before this driver is
> ready for upstream inclusion.
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/6] cxlflash: Resolve oops in wait_port_offline
Acked-by: Matthew R. Ochs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/6] cxlflash: Enable device id for future IBM CXL adapter
Acked-by: Matthew R. Ochs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/6] cxlflash: Fix to resolve cmd leak after host reset
Acked-by: Matthew R. Ochs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/6] cxlflash: Fix to escalate LINK_RESET also on port 1
Acked-by: Matthew R. Ochs ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/6] cxlflash: Enable device id for future IBM CXL adapter
On 12/13/2015 9:47 PM, Andrew Donnellan wrote: On 11/12/15 09:54, Uma Krishnan wrote: From: Manoj Kumar This drop enables a future card with a device id of 0x0600 to be recognized by the cxlflash driver. No card specific programming has been added. These card specific changes will be staged in later. Signed-off-by: Manoj N. Kumar Without the card-specific code, how does the driver behave if the new card is plugged in? Andrew: As per the design, the Accelerator Function Unit (AFU) for this new IBM CXL Flash Adapater retains the same host interface as the previous generation. For the early prototypes of the new card, the driver with this change behaves exactly as the driver prior to this behaved with the earlier generation card. i.e. No card specific changes are required. However, I left the staging comment in there, in case later versions of the card deviate from the prototype. - Manoj ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] tools lib bpf: Support libbpf on PowerPC
On 2015/12/14 11:57AM, Wang Nan wrote:
> Support basic PowerPC compiling.
>
> Checks BPF syscall number, turn off libbpf building on platform doesn't
> support sys_bpf instead of blocking compiling.
>
> Reported-by: Naveen N. Rao
> Signed-off-by: Wang Nan
> Cc: Arnaldo Carvalho de Melo
> Cc: Alexei Starovoitov
> Cc: Jiri Olsa
> Cc: Sukadev Bhattiprolu
> ---
>
> v1 -> v2: __powerpc64__ -> __powerpc__. Code is from
> ./tools/perf/perf-sys.h, but not tested yet.
>
> Naveen, please help me try this patch on PPC.
Thanks, this works. However...
>
> Thank you.
>
> ---
> tools/build/feature/test-bpf.c | 23 ++-
> tools/lib/bpf/bpf.c| 6 --
> 2 files changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/tools/build/feature/test-bpf.c b/tools/build/feature/test-bpf.c
> index 062bac8..19497f7 100644
> --- a/tools/build/feature/test-bpf.c
> +++ b/tools/build/feature/test-bpf.c
> @@ -1,9 +1,26 @@
> +#include
> #include
> +#include
> +
> +#ifndef __NR_bpf
> +# if defined(__i386__)
> +# define __NR_bpf 357
> +# elif defined(__x86_64__)
> +# define __NR_bpf 321
> +# elif defined(__aarch64__)
> +# define __NR_bpf 280
> +# elif defined(__powerpc__)
> +# define __NR_bpf 361
I think we should drop __aarch64__ and __powerpc__ here since this
builds fine on ppc without these hunks.
> +# else
> +# error __NR_bpf not defined. libbpf does not support your arch.
> +# endif
> +#endif
>
> int main(void)
> {
> union bpf_attr attr;
>
> + /* Check fields in attr */
> attr.prog_type = BPF_PROG_TYPE_KPROBE;
> attr.insn_cnt = 0;
> attr.insns = 0;
> @@ -14,5 +31,9 @@ int main(void)
> attr.kern_version = 0;
>
> attr = attr;
> - return 0;
> + /*
> + * Test existance of __NR_bpf and BPF_PROG_LOAD.
Nit... 'for existence'.
> + * This call should fail if we run the testcase.
> + */
> + return syscall(__NR_bpf, BPF_PROG_LOAD, attr, sizeof(attr));
> }
> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
> index 5bdc6ea..fd25c58 100644
> --- a/tools/lib/bpf/bpf.c
> +++ b/tools/lib/bpf/bpf.c
> @@ -14,8 +14,8 @@
> #include "bpf.h"
>
> /*
> - * When building perf, unistd.h is override. Define __NR_bpf is
> - * required to be defined.
> + * When building perf, unistd.h is overrided. __NR_bpf is
> + * required to be defined explicitly.
> */
> #ifndef __NR_bpf
> # if defined(__i386__)
> @@ -24,6 +24,8 @@
> # define __NR_bpf 321
> # elif defined(__aarch64__)
> # define __NR_bpf 280
> +# elif defined(__powerpc__)
> +# define __NR_bpf 361
And, I think we should drop this hunk, but include the patch I sent.
That ensures that the proper headers from the kernel source tree are
included, so there won't be a need to explicitly define __NR_bpf for
each architecture.
Regards,
Naveen
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] perf: bpf: Fix build breakage due to libbpf
On 2015/12/14 07:53PM, Wang Nan wrote:
> Hi Naveen,
>
> On 2015/12/14 18:50, Naveen N. Rao wrote:
> >perf build is currently (v4.4-rc5) broken on powerpc:
> >
> >bpf.c:28:4: error: #error __NR_bpf not defined. libbpf does not support
> >your arch.
> > # error __NR_bpf not defined. libbpf does not support your arch.
> > ^
> >
> >Fix this by including tools/perf/config/Makefile.arch for the proper
> >$ARCH macro. While at it, remove redundant LP64 macro definition.
> >
> >Signed-off-by: Naveen N. Rao
> >---
> > tools/lib/bpf/Makefile | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> >diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
> >index 636e3dd..050e0e8 100644
> >--- a/tools/lib/bpf/Makefile
> >+++ b/tools/lib/bpf/Makefile
> >@@ -31,7 +31,8 @@ INSTALL = install
> > DESTDIR ?=
> > DESTDIR_SQ = '$(subst ','\'',$(DESTDIR))'
> >-LP64 := $(shell echo __LP64__ | ${CC} ${CFLAGS} -E -x c - | tail -n 1)
> >+include $(srctree)/tools/perf/config/Makefile.arch
> >+
> > ifeq ($(LP64), 1)
> >libdir_relative = lib64
> > else
>
> Are you doing cross compiling? In this case you should provide an 'ARCH' to
> make
> through cmdline. For example, this is how yocto help me build perf on
> aarch64:
>
> $ make -C /patch/to/kernel/tools/perf O=/path/to/output \
> CROSS_COMPILE=aarch64-oe-linux- ARCH=arm64 \
> CC=aarch64-oe-linux-gcc --sysroot=... AR=aarch64-oe-linux-ar ...
I am not cross-compiling - the build error was with trying to build perf
on ppc64le. Even with cross-compiling (and explicitly specifying $ARCH),
Makefile.arch should still work.
>
> If you include Makefile.arch, I think you are seeking for a 'uname -m'
> result,
> then you are not doing cross compiling, right? In this case what you need is
> providing
> a __NR_bpf entry for your platform, because in some cases that value is
> overrided because
> we have
>
> $ find ./tools/ -name "unistd*"
> ./tools/perf/util/include/asm/unistd_64.h
> ./tools/perf/util/include/asm/unistd_32.h
>
> You can find the reason of these two files through:
> eae7a755ee81129370c8f555b0d5672e6673735d
I thought of just defining __NR_bpf for powerpc, but it will still break
perf build for most other architectures. Moreover,
tools/lib/bpf/Makefile explicitly includes headers from the linux kernel
build tree (rather than the system headers) and I thought this was
specifically to pull in __NR_bpf, among others -- just that we were not
properly including the right headers since $ARCH was not defined. More
specifically:
$ make V=1
gcc -Wp,-MD,./.bpf.o.d,-MT,bpf.o -g -Wall -DHAVE_LIBELF_MMAP_SUPPORT
-DHAVE_ELF_GETPHDRNUM_SUPPORT -Wbad-function-cast
-Wdeclaration-after-statement -Wformat-security -Wformat-y2k
-Winit-self -Wmissing-declarations -Wmissing-prototypes
-Wnested-externs -Wno-system-headers -Wold-style-definition -Wpacked
-Wredundant-decls -Wshadow -Wstrict-aliasing=3 -Wstrict-prototypes
-Wswitch-default -Wswitch-enum -Wundef -Wwrite-strings -Wformat
-Werror -Wall -fPIC -I. -I/root/linux/tools/include
-I/root/linux/arch//include/uapi -I/root/linux/include/uapi
-D"BUILD_STR(s)=#s" -c -o bpf.o bpf.c
Notice // in -I/root/linux/arch//include/uapi. Hence, my patch to ensure
the right headers get included.
I'm thinking the explicit __NR_bpf definitions are only needed for x86
-- since I don't see the definitions in the kernel tree headers.
Regards,
Naveen
>
> I posted a patch by replying this mail. I think you can find it through [1]
> soon.
> I don't have PPC environment to check it. Could you please help me check
> this patch
> in your environment?
>
> [1]
> http://lkml.kernel.org/g/1450092932-123588-1-git-send-email-wangn...@huawei.com
>
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] tools lib bpf: Support libbpf on PowerPC
Support basic PowerPC compiling.
Checks BPF syscall number, turn off libbpf building on platform doesn't
support sys_bpf instead of blocking compiling.
Reported-by: Naveen N. Rao
Signed-off-by: Wang Nan
Cc: Arnaldo Carvalho de Melo
Cc: Alexei Starovoitov
Cc: Jiri Olsa
Cc: Sukadev Bhattiprolu
---
v1 -> v2: __powerpc64__ -> __powerpc__. Code is from
./tools/perf/perf-sys.h, but not tested yet.
Naveen, please help me try this patch on PPC.
Thank you.
---
tools/build/feature/test-bpf.c | 23 ++-
tools/lib/bpf/bpf.c| 6 --
2 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/tools/build/feature/test-bpf.c b/tools/build/feature/test-bpf.c
index 062bac8..19497f7 100644
--- a/tools/build/feature/test-bpf.c
+++ b/tools/build/feature/test-bpf.c
@@ -1,9 +1,26 @@
+#include
#include
+#include
+
+#ifndef __NR_bpf
+# if defined(__i386__)
+# define __NR_bpf 357
+# elif defined(__x86_64__)
+# define __NR_bpf 321
+# elif defined(__aarch64__)
+# define __NR_bpf 280
+# elif defined(__powerpc__)
+# define __NR_bpf 361
+# else
+# error __NR_bpf not defined. libbpf does not support your arch.
+# endif
+#endif
int main(void)
{
union bpf_attr attr;
+ /* Check fields in attr */
attr.prog_type = BPF_PROG_TYPE_KPROBE;
attr.insn_cnt = 0;
attr.insns = 0;
@@ -14,5 +31,9 @@ int main(void)
attr.kern_version = 0;
attr = attr;
- return 0;
+ /*
+* Test existance of __NR_bpf and BPF_PROG_LOAD.
+* This call should fail if we run the testcase.
+*/
+ return syscall(__NR_bpf, BPF_PROG_LOAD, attr, sizeof(attr));
}
diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
index 5bdc6ea..fd25c58 100644
--- a/tools/lib/bpf/bpf.c
+++ b/tools/lib/bpf/bpf.c
@@ -14,8 +14,8 @@
#include "bpf.h"
/*
- * When building perf, unistd.h is override. Define __NR_bpf is
- * required to be defined.
+ * When building perf, unistd.h is overrided. __NR_bpf is
+ * required to be defined explicitly.
*/
#ifndef __NR_bpf
# if defined(__i386__)
@@ -24,6 +24,8 @@
# define __NR_bpf 321
# elif defined(__aarch64__)
# define __NR_bpf 280
+# elif defined(__powerpc__)
+# define __NR_bpf 361
# else
# error __NR_bpf not defined. libbpf does not support your arch.
# endif
--
1.8.3.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] perf: bpf: Fix build breakage due to libbpf
Hi Naveen,
On 2015/12/14 18:50, Naveen N. Rao wrote:
perf build is currently (v4.4-rc5) broken on powerpc:
bpf.c:28:4: error: #error __NR_bpf not defined. libbpf does not support
your arch.
# error __NR_bpf not defined. libbpf does not support your arch.
^
Fix this by including tools/perf/config/Makefile.arch for the proper
$ARCH macro. While at it, remove redundant LP64 macro definition.
Signed-off-by: Naveen N. Rao
---
tools/lib/bpf/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
index 636e3dd..050e0e8 100644
--- a/tools/lib/bpf/Makefile
+++ b/tools/lib/bpf/Makefile
@@ -31,7 +31,8 @@ INSTALL = install
DESTDIR ?=
DESTDIR_SQ = '$(subst ','\'',$(DESTDIR))'
-LP64 := $(shell echo __LP64__ | ${CC} ${CFLAGS} -E -x c - | tail -n 1)
+include $(srctree)/tools/perf/config/Makefile.arch
+
ifeq ($(LP64), 1)
libdir_relative = lib64
else
Are you doing cross compiling? In this case you should provide an 'ARCH'
to make
through cmdline. For example, this is how yocto help me build perf on
aarch64:
$ make -C /patch/to/kernel/tools/perf O=/path/to/output \
CROSS_COMPILE=aarch64-oe-linux- ARCH=arm64 \
CC=aarch64-oe-linux-gcc --sysroot=...
AR=aarch64-oe-linux-ar ...
If you include Makefile.arch, I think you are seeking for a 'uname -m'
result,
then you are not doing cross compiling, right? In this case what you
need is providing
a __NR_bpf entry for your platform, because in some cases that value is
overrided because
we have
$ find ./tools/ -name "unistd*"
./tools/perf/util/include/asm/unistd_64.h
./tools/perf/util/include/asm/unistd_32.h
You can find the reason of these two files through:
eae7a755ee81129370c8f555b0d5672e6673735d
I posted a patch by replying this mail. I think you can find it through
[1] soon.
I don't have PPC environment to check it. Could you please help me check
this patch
in your environment?
[1]
http://lkml.kernel.org/g/1450092932-123588-1-git-send-email-wangn...@huawei.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 4/4] printk/nmi: Increase the size of NMI buffer and make it configurable
On 11/12/15 23:21, Russell King - ARM Linux wrote: As I explained when I did that work, the vast majority of ARM platforms are unable to trigger anything like a NMI - the FIQ is something that's generally a property of the secure monitor, and is not accessible to Linux. However, there are platforms where it is accessible. The work to add the FIQ-based variant never happened (I've no idea what happened to that part, Daniel seems to have lost interest in working on it.) So, what we have is the IRQ-based variant merged in mainline, which would be the fallback for the "FIQ not available" cases, and I carry a local hack in my tree which provides the FIQ-based version - but if it were to trigger, it takes out all interrupts (hence why I've not merged my hack.) I think the reason that the FIQ-based variant has never really happened is that hooking into the interrupt controller code to clear down the FIQ creates such a horrid layering violation, and also a locking mess that I suspect it's just been given up with. I haven't quite given up; I'm still looking into this stuff. However you're certainly right that connecting the FIQ handler to the GIC code in an elegant way is tough. I've been working in parallel on an arm64 implementation with the result that I'm now two lumps of code that are almost, but not quite, ready. Right now I hope to share latest arm code fairly late in the this devcycle (for review rather than merge) followed up with a new version very early in v4.6. Even now I think the code needs a long soak in -next just in case there are any lurking regressions on particular platforms. I don't expect anyone to base decisions on my aspirations above but would like to reassure Russell that I haven't given up on it. Daniel. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] tools lib bpf: Support libbpf on PowerPC
Support basic PowerPC compiling.
Checks BPF syscall number, turn off libbpf building on platform doesn't
support sys_bpf instead of blocking compiling.
Reported-by: Naveen N. Rao
Signed-off-by: Wang Nan
Cc: Arnaldo Carvalho de Melo
Cc: Alexei Starovoitov
Cc: Jiri Olsa
Cc: Sukadev Bhattiprolu
---
Hi Naveen,
I don't have PPC environtment. Could you please help me check this patch?
Thank you.
---
tools/build/feature/test-bpf.c | 23 ++-
tools/lib/bpf/bpf.c| 6 --
2 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/tools/build/feature/test-bpf.c b/tools/build/feature/test-bpf.c
index 062bac8..dc119ec 100644
--- a/tools/build/feature/test-bpf.c
+++ b/tools/build/feature/test-bpf.c
@@ -1,9 +1,26 @@
+#include
#include
+#include
+
+#ifndef __NR_bpf
+# if defined(__i386__)
+# define __NR_bpf 357
+# elif defined(__x86_64__)
+# define __NR_bpf 321
+# elif defined(__aarch64__)
+# define __NR_bpf 280
+# elif defined(__powerpc64__)
+# define __NR_bpf 361
+# else
+# error __NR_bpf not defined. libbpf does not support your arch.
+# endif
+#endif
int main(void)
{
union bpf_attr attr;
+ /* Check fields in attr */
attr.prog_type = BPF_PROG_TYPE_KPROBE;
attr.insn_cnt = 0;
attr.insns = 0;
@@ -14,5 +31,9 @@ int main(void)
attr.kern_version = 0;
attr = attr;
- return 0;
+ /*
+* Test existance of __NR_bpf and BPF_PROG_LOAD.
+* This call should fail.
+*/
+ return syscall(__NR_bpf, BPF_PROG_LOAD, attr, sizeof(attr));
}
diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
index 5bdc6ea..b68c9e2 100644
--- a/tools/lib/bpf/bpf.c
+++ b/tools/lib/bpf/bpf.c
@@ -14,8 +14,8 @@
#include "bpf.h"
/*
- * When building perf, unistd.h is override. Define __NR_bpf is
- * required to be defined.
+ * When building perf, unistd.h is overrided. __NR_bpf is
+ * required to be defined explicitly.
*/
#ifndef __NR_bpf
# if defined(__i386__)
@@ -24,6 +24,8 @@
# define __NR_bpf 321
# elif defined(__aarch64__)
# define __NR_bpf 280
+# elif defined(__powerpc64__)
+# define __NR_bpf 361
# else
# error __NR_bpf not defined. libbpf does not support your arch.
# endif
--
1.8.3.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] perf: bpf: Fix build breakage due to libbpf
perf build is currently (v4.4-rc5) broken on powerpc:
bpf.c:28:4: error: #error __NR_bpf not defined. libbpf does not support
your arch.
# error __NR_bpf not defined. libbpf does not support your arch.
^
Fix this by including tools/perf/config/Makefile.arch for the proper
$ARCH macro. While at it, remove redundant LP64 macro definition.
Signed-off-by: Naveen N. Rao
---
tools/lib/bpf/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
index 636e3dd..050e0e8 100644
--- a/tools/lib/bpf/Makefile
+++ b/tools/lib/bpf/Makefile
@@ -31,7 +31,8 @@ INSTALL = install
DESTDIR ?=
DESTDIR_SQ = '$(subst ','\'',$(DESTDIR))'
-LP64 := $(shell echo __LP64__ | ${CC} ${CFLAGS} -E -x c - | tail -n 1)
+include $(srctree)/tools/perf/config/Makefile.arch
+
ifeq ($(LP64), 1)
libdir_relative = lib64
else
--
2.6.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/mm: Fix infinite loop in hash fault with 4K page size
On Sat, 2015-28-11 at 17:09:33 UTC, "Aneesh Kumar K.V" wrote:
> This is the same bug we fixed as part of
> 09567e7fd44291bfc08accfdd67ad8f467842332
> ("powerpc/mm: Check paca psize is up to date for huge mappings"). Please
> check that for details. The difference here is that faults were
> happening on a 4K page at an address previously mapped by hugetlb.
>
> Signed-off-by: Aneesh Kumar K.V
> Reviewed-by: Anshuman Khandual
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/0863d7f2136550a281f40f4d
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [V6,01/35] powerpc/mm: move pte headers to book3s directory
On Tue, 2015-01-12 at 03:36:26 UTC, "Aneesh Kumar K.V" wrote: > Acked-by: Scott Wood > Signed-off-by: Aneesh Kumar K.V Entire series applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/26b6a3d9bb48f8b4624a6228 cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: tracing: don't trace hcalls on offline CPUs
On 12/14/15, Michael Ellerman wrote: > On Mon, 2015-12-07 at 16:33 -0500, Steven Rostedt wrote: >> On Tue, 08 Dec 2015 08:02:15 +1100 >> Benjamin Herrenschmidt wrote: >> > On Mon, 2015-12-07 at 15:52 -0500, Steven Rostedt wrote: >> > > > + TP_CONDITION(cpu_online(smp_processor_id())), >> > > > + >> > >> > This should probably be some kind of __raw version though, hcalls can >> > be called in contexts where the debug stuff in smp_processor_id() isn't >> > safe (or preempt enabled). >> > >> >> OK, then that needs to be updated. > > Denis, please respin with raw_smp_processor_id(). Sure, I'll respin today. Thanks! > > cheers > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: tracing: don't trace hcalls on offline CPUs
On Mon, 2015-12-07 at 16:33 -0500, Steven Rostedt wrote: > On Tue, 08 Dec 2015 08:02:15 +1100 > Benjamin Herrenschmidt wrote: > > On Mon, 2015-12-07 at 15:52 -0500, Steven Rostedt wrote: > > > > + TP_CONDITION(cpu_online(smp_processor_id())), > > > > + > > > > This should probably be some kind of __raw version though, hcalls can > > be called in contexts where the debug stuff in smp_processor_id() isn't > > safe (or preempt enabled). > > > > OK, then that needs to be updated. Denis, please respin with raw_smp_processor_id(). cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc: Fix DSCR inheritance over fork()
On Wed, 2015-09-12 at 09:11:47 UTC, Anton Blanchard wrote: > Two DSCR tests have a hack in them: > > /* >* XXX: Force a context switch out so that DSCR >* current value is copied into the thread struct >* which is required for the child to inherit the >* changed value. >*/ > sleep(1); > > We should not be working around this in the testcase, it is a kernel bug. > Fix it by copying the current DSCR to the child, instead of what we > had in the thread struct at last context switch. > > Signed-off-by: Anton Blanchard Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/db1231dcdb4dc6cdcbdef0ba cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v2] powerpc: Call restore_sprs() before _switch()
On Thu, 2015-10-12 at 09:44:39 UTC, Anton Blanchard wrote:
> commit 152d523e6307 ("powerpc: Create context switch helpers save_sprs()
> and restore_sprs()") moved the restore of SPRs after the call to _switch().
>
> There is an issue with this approach - new tasks do not return through
> _switch(), they are set up by copy_thread() to directly return through
> ret_from_fork() or ret_from_kernel_thread(). This means restore_sprs() is
> not getting called for new tasks.
>
> Fix this by moving restore_sprs() before _switch().
>
> Signed-off-by: Anton Blanchard
> Fixes: 152d523e6307 ("powerpc: Create context switch helpers save_sprs() and
> restore_sprs()")
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/20dbe67062062c2a790832f0
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc: Call check_if_tm_restore_required() in enable_kernel_*()
On Thu, 2015-10-12 at 09:04:05 UTC, Anton Blanchard wrote:
> Commit a0e72cf12b1a ("powerpc: Create msr_check_and_{set,clear}()")
> removed a call to check_if_tm_restore_required() in the
> enable_kernel_*() functions. Add them back in.
>
> Fixes: a0e72cf12b1a ("powerpc: Create msr_check_and_{set,clear}()")
> Reported-by: Rashmica Gupta
> Signed-off-by: Anton Blanchard
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/d64d02ce4ebaa79bf1c026e8
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: sbc8641: drop bogus PHY IRQ entries from DTS file
On Tue, 2015-08-12 at 22:44:02 UTC, Paul Gortmaker wrote:
> This file was originally cloned off of the MPC8641D-HPCN reference
> platform, which actually had a PHY IRQ line connected. However
> this board does not. The bogus entry was largely inert and went
> undetected until commit 321beec5047af83db90c88114b7e664b156f49fe
> ("net: phy: Use interrupts when available in NOLINK state") was
> added to the tree.
>
> With the above commit, the board fails to NFS boot since it sits
> waiting for a PHY IRQ event that of course never arrives. Removing
> the bogus entries from the DTS file fixes the issue.
>
> Cc: Andrew Lunn
> Signed-off-by: Paul Gortmaker
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/5b01310cfc8d2302dcca1d8d
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v2] Revert "powerpc/eeh: Don't unfreeze PHB PE after reset"
On Tue, 2015-08-12 at 05:59:25 UTC, Andrew Donnellan wrote: > This reverts commit 527d10ef3a315d3cb9dc098dacd61889a6c26439. > > The reverted commit breaks cxlflash devices following an EEH reset (and > possibly other cxl devices, however this has not been tested). ... > > In the meantime, revert the commit, especially as it was intended to be a > non-functional change. > > Cc: Gavin Shan > Cc: Ian Munsie > Cc: Daniel Axtens > Signed-off-by: Andrew Donnellan Applied to powerpc fixes, thanks. https://git.kernel.org/powerpc/c/dc9c41bd9ece090b54eb8f1b cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powernv/opal-irqchip: Fix double endian conversion
On Mon, 2015-07-12 at 00:28:28 UTC, Alistair Popple wrote: > The OPAL event calls return a mask of events that are active in big > endian format. This is checked when unmasking the events in the > irqchip by comparison with a cached value. The cached value was stored > in big endian format but should've been converted to CPU endian > first. This bug leads to OPAL event delivery being delayed or dropped > on some systems. > > The bug is fixed by calling opal_handle_events(...) instead of > duplicating code in opal_event_unmask(...). > > Signed-off-by: Alistair Popple > Reported-by: Douglas L Lehr > Cc: sta...@vger.kernel.org Applied to powerpc fixes, thanks. https://git.kernel.org/powerpc/c/25642e1459ace29f6ce5a171 cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: cxl: Set endianess of kernel contexts
On Mon, 2015-07-12 at 13:34:40 UTC, Frederic Barrat wrote: > A process element (defined in CAIA) keeps track of the endianess of > contexts through the Little Endian (LE) bit of the State Register. It > is currently set for user contexts, but was somehow forgotten for > kernel contexts, so this patch fixes it. > It could lead to erratic behavior from an AFU when the context is > attached through the kernel API. > > Signed-off-by: Frederic Barrat > Suggested-by: Michael Neuling > Cc: # 4.3+ Applied to powerpc fixes, thanks. https://git.kernel.org/powerpc/c/e606e035cc7293a3824527d9 cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v2] platforms/powernv: Add support for Nvlink NPUs
Hi Alistair,
Just a few nitty things ...
On Tue, 2015-10-11 at 02:28:11 UTC, Alistair Popple wrote:
> NV-Link is a high speed interconnect that is used in conjunction with
Is it NV-Link or NVLink?
> a PCI-E connection to create an interface between CPU and GPU that
> provides very high data bandwidth. A PCI-E connection to a GPU is used
> as the control path to initiate and report status of large data
> transfers sent via the NV-Link.
>
> On IBM Power systems the NV-Link hardware interface is very similar to
> the existing PHB3. This patch adds support for this new NPU PHB
NPU ?
> type. DMA operations on the NPU are not supported as this patch sets
> the TCE translation tables to be the same as the related GPU PCIe
> device for each Nvlink. Therefore all DMA operations are setup and
> controlled via the PCIe device.
>
> EEH is not presently supported for the NPU devices, although it may be
> added in future.
>
> Signed-off-by: Alistair Popple
> Signed-off-by: Gavin Shan
> ---
>
> This patch includes the following changes from v1:
> - Minor variable name updates and code refactors suggested by Gavin
> - Fixes for an issue with TCE cache invalidation
>
> arch/powerpc/include/asm/pci.h| 4 +
> arch/powerpc/platforms/powernv/Makefile | 2 +-
> arch/powerpc/platforms/powernv/npu-dma.c | 339
> ++
> arch/powerpc/platforms/powernv/pci-ioda.c | 132 +++-
> arch/powerpc/platforms/powernv/pci.c | 4 +
> arch/powerpc/platforms/powernv/pci.h | 19 ++
> 6 files changed, 488 insertions(+), 12 deletions(-)
> create mode 100644 arch/powerpc/platforms/powernv/npu-dma.c
>
> --
> 2.1.4
>
> diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
> index 3453bd8..6f8065a 100644
> --- a/arch/powerpc/include/asm/pci.h
> +++ b/arch/powerpc/include/asm/pci.h
> @@ -149,4 +149,8 @@ extern void pcibios_setup_phb_io_space(struct
> pci_controller *hose);
> extern void pcibios_scan_phb(struct pci_controller *hose);
>
> #endif /* __KERNEL__ */
> +
> +extern struct pci_dev *pnv_pci_get_gpu_dev(struct pci_dev *npdev);
> +extern struct pci_dev *pnv_pci_get_npu_dev(struct pci_dev *gpdev, int index);
> +
> #endif /* __ASM_POWERPC_PCI_H */
> diff --git a/arch/powerpc/platforms/powernv/Makefile
> b/arch/powerpc/platforms/powernv/Makefile
> index 1c8cdb6..ee774e8 100644
> --- a/arch/powerpc/platforms/powernv/Makefile
> +++ b/arch/powerpc/platforms/powernv/Makefile
> @@ -4,7 +4,7 @@ obj-y += rng.o opal-elog.o opal-dump.o
> opal-sysparam.o opal-sensor.o
> obj-y+= opal-msglog.o opal-hmi.o opal-power.o
> opal-irqchip.o
>
> obj-$(CONFIG_SMP)+= smp.o subcore.o subcore-asm.o
> -obj-$(CONFIG_PCI)+= pci.o pci-p5ioc2.o pci-ioda.o
> +obj-$(CONFIG_PCI)+= pci.o pci-p5ioc2.o pci-ioda.o npu-dma.o
> obj-$(CONFIG_EEH)+= eeh-powernv.o
> obj-$(CONFIG_PPC_SCOM) += opal-xscom.o
> obj-$(CONFIG_MEMORY_FAILURE) += opal-memory-errors.o
> diff --git a/arch/powerpc/platforms/powernv/npu-dma.c
> b/arch/powerpc/platforms/powernv/npu-dma.c
> new file mode 100644
> index 000..a1e5ba5
> --- /dev/null
> +++ b/arch/powerpc/platforms/powernv/npu-dma.c
> @@ -0,0 +1,339 @@
> +/*
> + * This file implements the DMA operations for Nvlink devices. The NPU
> + * devices all point to the same iommu table as the parent PCI device.
> + *
> + * Copyright Alistair Popple, IBM Corporation 2015.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
Can you drop the any later part, that's not generally true, see COPYING.
eg:
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2 of the GNU Lesser General Public License
+ * as published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include "powernv.h"
> +#include "pci.h"
> +
> +static struct pci_dev *get_pci_dev(struct device_node *dn)
> +{
> + return PCI_DN(dn)->pcidev;
> +}
> +
> +/* Given a NPU device get the associated PCI device. */
> +struct pci_dev *pnv_pci_get_gpu_dev(struct pci_dev *npdev)
> +{
> + struct device_node *dn;
> + struct pci_dev *gpdev;
> +
> + /* Get assoicated PCI device */
> + dn = of_parse_phandle(npdev->dev.of_node, "ibm,gpu", 0);
> + if (!dn)
> + return NULL;
> +
> + gpdev = get_pci_dev(dn);
> + of_node_put(dn);
> +
> + return gpdev;
> +}
> +EXPORT_SYMBOL(pnv_pci_get_gpu_dev);
> +
> +/* Given the real PCI device get a linked NPU device. */
> +struct pci_dev *pnv_pci_get_npu_dev(struct pci_dev *gpdev, int index)
> +{
> + struct device_node *dn;
> + struct pci_dev *npdev;
> +
> + /* Get assoicate
