* Re: samples/seccomp/ broken when cross compiling s390, ppc allyesconfig
From: Michal Hocko @ 2018-02-22 13:07 UTC (permalink / raw)
To: Kees Cook; +Cc: Michael Ellerman, Will Drewry, linux-s390, PowerPC, LKML
In-Reply-To: <CAGXu5jJCN_Js9rvM4RMjxDCDd4tVzWDo-jdnFiZs1D9e3cunrw@mail.gmail.com>
On Wed 14-02-18 09:14:47, Kees Cook wrote:
[...]
> I can send it through my seccomp tree via James Morris.
Could you please do it?
> >
> > From 8d8457e96296538508e478f598d1c8b3406a8626 Mon Sep 17 00:00:00 2001
> > From: Michal Hocko <mhocko@suse.com>
> > Date: Wed, 14 Feb 2018 10:15:12 +0100
> > Subject: [PATCH] samples/seccomp: do not compile when cross compiled
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: 8bit
> >
> > samples/seccomp relies on the host setting which is not suitable for
> > crosscompilation and it actually fails when crosscompiling s390 and
> > powerpc all{yes,mod}config on x86_64 with
> >
> > samples/seccomp/bpf-helper.h:135:2: error: #error __BITS_PER_LONG value unusable.
> > #error __BITS_PER_LONG value unusable.
> > ^
> > In file included from samples/seccomp/bpf-fancy.c:13:0:
> > samples/seccomp/bpf-fancy.c: In function ‘main’:
> > samples/seccomp/bpf-fancy.c:38:11: error: ‘__NR_exit’ undeclared (first use in this function)
> > SYSCALL(__NR_exit, ALLOW),
> >
> > and many others. I am doing these for compile testing and it's been
> > quite useful to catch issues. Crosscompiling sample code on the other
> > hand doesn't seem all that important so it seems like the easiest way to
> > simply disable samples/seccomp when crosscompiling.
> >
> > Fixing this properly is not that easy as Kees explains:
> > : IIRC, one of the problems is with build ordering problems: the kernel
> > : headers used by the samples aren't available when cross compiling.
> >
> > Acked-by: Kees Cook <keescook@chromium.org>
> > Signed-off-by: Michal Hocko <mhocko@suse.com>
> > ---
> > samples/seccomp/Makefile | 10 +---------
> > 1 file changed, 1 insertion(+), 9 deletions(-)
> >
> > diff --git a/samples/seccomp/Makefile b/samples/seccomp/Makefile
> > index 0e349b80686e..ba942e3ead89 100644
> > --- a/samples/seccomp/Makefile
> > +++ b/samples/seccomp/Makefile
> > @@ -1,4 +1,5 @@
> > # SPDX-License-Identifier: GPL-2.0
> > +ifndef CROSS_COMPILE
> > hostprogs-$(CONFIG_SAMPLE_SECCOMP) := bpf-fancy dropper bpf-direct
> >
> > HOSTCFLAGS_bpf-fancy.o += -I$(objtree)/usr/include
> > @@ -16,7 +17,6 @@ HOSTCFLAGS_bpf-direct.o += -idirafter $(objtree)/include
> > bpf-direct-objs := bpf-direct.o
> >
> > # Try to match the kernel target.
> > -ifndef CROSS_COMPILE
> > ifndef CONFIG_64BIT
> >
> > # s390 has -m31 flag to build 31 bit binaries
> > @@ -35,12 +35,4 @@ HOSTLOADLIBES_bpf-fancy += $(MFLAG)
> > HOSTLOADLIBES_dropper += $(MFLAG)
> > endif
> > always := $(hostprogs-m)
> > -else
> > -# MIPS system calls are defined based on the -mabi that is passed
> > -# to the toolchain which may or may not be a valid option
> > -# for the host toolchain. So disable tests if target architecture
> > -# is MIPS but the host isn't.
> > -ifndef CONFIG_MIPS
> > -always := $(hostprogs-m)
> > -endif
> > endif
> > --
> > 2.15.1
> >
> > --
> > Michal Hocko
> > SUSE Labs
>
>
>
> --
> Kees Cook
> Pixel Security
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH v3 2/4] gpio: Add GPIO driver for Nintendo Wii
From: Linus Walleij @ 2018-02-22 12:57 UTC (permalink / raw)
To: Jonathan Neuschäfer
Cc: linux-kernel@vger.kernel.org, Joel Stanley,
linuxppc-dev@lists.ozlabs.org list, linux-gpio,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Albert Herranz, Segher Boessenkool
In-Reply-To: <20180209120732.17863-3-j.neuschaefer@gmx.net>
On Fri, Feb 9, 2018 at 1:07 PM, Jonathan Neusch=C3=A4fer
<j.neuschaefer@gmx.net> wrote:
> The Nintendo Wii's chipset (called "Hollywood") has a GPIO controller
> that supports a configurable number of pins (up to 32), interrupts, and
> some special mechanisms to share the controller between the system's
> security processor (an ARM926) and the PowerPC CPU. Pin multiplexing is
> not supported.
>
> This patch adds a basic driver for this GPIO controller. Interrupt
> support will come in a later patch.
>
> This patch is based on code developed by Albert Herranz and the GameCube
> Linux Team, file arch/powerpc/platforms/embedded6xx/hlwd-gpio.c,
> available at https://github.com/DeltaResero/GC-Wii-Linux-Kernels, but
> has grown quite dissimilar.
>
> Signed-off-by: Jonathan Neusch=C3=A4fer <j.neuschaefer@gmx.net>
> Cc: Albert Herranz <albert_herranz@yahoo.es>
> Cc: Segher Boessenkool <segher@kernel.crashing.org>
> <---
>
> v3:
> - Do some style cleanups, as suggest by Andy Shevchenko
Patch applied to the GPIO tree for v4.17 with all the review tags.
I just folded the changelog into the commit message, for new
drivers it is sometimes useful to keep these around in
git actually.
If any further changes are needed we can just patch on top
of this.
It's a very pretty driver, good work!
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v4.4 backport 2/3] powerpc/64s: Simple RFI macro conversions
From: Michael Ellerman @ 2018-02-22 12:35 UTC (permalink / raw)
To: stable, greg; +Cc: npiggin, linuxppc-dev, linux, corsac
In-Reply-To: <20180222123545.8946-1-mpe@ellerman.id.au>
From: Nicholas Piggin <npiggin@gmail.com>
commit 222f20f140623ef6033491d0103ee0875fe87d35 upstream.
This commit does simple conversions of rfi/rfid to the new macros that
include the expected destination context. By simple we mean cases
where there is a single well known destination context, and it's
simply a matter of substituting the instruction for the appropriate
macro.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
[mpe: Backport to 4.9, use RFI_TO_KERNEL in idle_book3s.S]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/exception-64s.h | 2 +-
arch/powerpc/kernel/entry_64.S | 14 +++++++++-----
arch/powerpc/kernel/exceptions-64s.S | 22 +++++++++++-----------
arch/powerpc/kernel/idle_book3s.S | 7 ++++---
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 7 +++----
arch/powerpc/kvm/book3s_rmhandlers.S | 7 +++++--
arch/powerpc/kvm/book3s_segment.S | 4 ++--
7 files changed, 35 insertions(+), 28 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h
index cab6d2a46c41..903e76a9f158 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -242,7 +242,7 @@ END_FTR_SECTION_NESTED(ftr,ftr,943)
mtspr SPRN_##h##SRR0,r12; \
mfspr r12,SPRN_##h##SRR1; /* and SRR1 */ \
mtspr SPRN_##h##SRR1,r10; \
- h##rfid; \
+ h##RFI_TO_KERNEL; \
b . /* prevent speculative execution */
#define EXCEPTION_PROLOG_PSERIES_1(label, h) \
__EXCEPTION_PROLOG_PSERIES_1(label, h)
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index c33b69d10919..2dc52e6d2af4 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -39,6 +39,11 @@
#include <asm/tm.h>
#include <asm/ppc-opcode.h>
#include <asm/export.h>
+#ifdef CONFIG_PPC_BOOK3S
+#include <asm/exception-64s.h>
+#else
+#include <asm/exception-64e.h>
+#endif
/*
* System calls.
@@ -396,8 +401,7 @@ tabort_syscall:
mtmsrd r10, 1
mtspr SPRN_SRR0, r11
mtspr SPRN_SRR1, r12
-
- rfid
+ RFI_TO_USER
b . /* prevent speculative execution */
#endif
@@ -1073,7 +1077,7 @@ _GLOBAL(enter_rtas)
mtspr SPRN_SRR0,r5
mtspr SPRN_SRR1,r6
- rfid
+ RFI_TO_KERNEL
b . /* prevent speculative execution */
rtas_return_loc:
@@ -1098,7 +1102,7 @@ rtas_return_loc:
mtspr SPRN_SRR0,r3
mtspr SPRN_SRR1,r4
- rfid
+ RFI_TO_KERNEL
b . /* prevent speculative execution */
.align 3
@@ -1169,7 +1173,7 @@ _GLOBAL(enter_prom)
LOAD_REG_IMMEDIATE(r12, MSR_SF | MSR_ISF | MSR_LE)
andc r11,r11,r12
mtsrr1 r11
- rfid
+ RFI_TO_KERNEL
#endif /* CONFIG_PPC_BOOK3E */
1: /* Return from OF */
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index d0be752ea86c..29892500e646 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -244,7 +244,7 @@ BEGIN_FTR_SECTION
LOAD_HANDLER(r12, machine_check_handle_early)
1: mtspr SPRN_SRR0,r12
mtspr SPRN_SRR1,r11
- rfid
+ RFI_TO_KERNEL
b . /* prevent speculative execution */
2:
/* Stack overflow. Stay on emergency stack and panic.
@@ -280,7 +280,7 @@ machine_check_pSeries_0:
mtspr SPRN_SRR0,r12
mfspr r12,SPRN_SRR1
mtspr SPRN_SRR1,r10
- rfid
+ RFI_TO_KERNEL
b . /* prevent speculative execution */
TRAMP_KVM_SKIP(PACA_EXMC, 0x200)
@@ -446,7 +446,7 @@ EXC_COMMON_BEGIN(machine_check_handle_early)
li r3,MSR_ME
andc r10,r10,r3 /* Turn off MSR_ME */
mtspr SPRN_SRR1,r10
- rfid
+ RFI_TO_KERNEL
b .
2:
/*
@@ -464,7 +464,7 @@ EXC_COMMON_BEGIN(machine_check_handle_early)
*/
bl machine_check_queue_event
MACHINE_CHECK_HANDLER_WINDUP
- rfid
+ RFI_TO_USER_OR_KERNEL
9:
/* Deliver the machine check to host kernel in V mode. */
MACHINE_CHECK_HANDLER_WINDUP
@@ -706,7 +706,7 @@ END_MMU_FTR_SECTION_IFCLR(MMU_FTR_TYPE_RADIX)
mtspr SPRN_SRR0,r10
ld r10,PACAKMSR(r13)
mtspr SPRN_SRR1,r10
- rfid
+ RFI_TO_KERNEL
b .
EXC_COMMON_BEGIN(unrecov_slb)
@@ -893,7 +893,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_REAL_LE) \
mtspr SPRN_SRR0,r10 ; \
ld r10,PACAKMSR(r13) ; \
mtspr SPRN_SRR1,r10 ; \
- rfid ; \
+ RFI_TO_KERNEL ; \
b . ; /* prevent speculative execution */
#define SYSCALL_PSERIES_3 \
@@ -901,7 +901,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_REAL_LE) \
1: mfspr r12,SPRN_SRR1 ; \
xori r12,r12,MSR_LE ; \
mtspr SPRN_SRR1,r12 ; \
- rfid ; /* return to userspace */ \
+ RFI_TO_USER ; /* return to userspace */ \
b . ; /* prevent speculative execution */
#if defined(CONFIG_RELOCATABLE)
@@ -1276,7 +1276,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_CFAR)
ld r11,PACA_EXGEN+EX_R11(r13)
ld r12,PACA_EXGEN+EX_R12(r13)
ld r13,PACA_EXGEN+EX_R13(r13)
- HRFID
+ HRFI_TO_UNKNOWN
b .
#endif
@@ -1350,7 +1350,7 @@ masked_##_H##interrupt: \
ld r10,PACA_EXGEN+EX_R10(r13); \
ld r11,PACA_EXGEN+EX_R11(r13); \
GET_SCRATCH0(r13); \
- ##_H##rfid; \
+ ##_H##RFI_TO_KERNEL; \
b .
/*
@@ -1372,7 +1372,7 @@ TRAMP_REAL_BEGIN(kvmppc_skip_interrupt)
addi r13, r13, 4
mtspr SPRN_SRR0, r13
GET_SCRATCH0(r13)
- rfid
+ RFI_TO_KERNEL
b .
TRAMP_REAL_BEGIN(kvmppc_skip_Hinterrupt)
@@ -1384,7 +1384,7 @@ TRAMP_REAL_BEGIN(kvmppc_skip_Hinterrupt)
addi r13, r13, 4
mtspr SPRN_HSRR0, r13
GET_SCRATCH0(r13)
- hrfid
+ HRFI_TO_KERNEL
b .
#endif
diff --git a/arch/powerpc/kernel/idle_book3s.S b/arch/powerpc/kernel/idle_book3s.S
index b350ac5e3111..d92c95333435 100644
--- a/arch/powerpc/kernel/idle_book3s.S
+++ b/arch/powerpc/kernel/idle_book3s.S
@@ -9,6 +9,7 @@
*/
#include <linux/threads.h>
+#include <asm/exception-64s.h>
#include <asm/processor.h>
#include <asm/page.h>
#include <asm/cputable.h>
@@ -178,7 +179,7 @@ _GLOBAL(pnv_powersave_common)
mtmsrd r6, 1 /* clear RI before setting SRR0/1 */
mtspr SPRN_SRR0, r5
mtspr SPRN_SRR1, r7
- rfid
+ RFI_TO_KERNEL
.globl pnv_enter_arch207_idle_mode
pnv_enter_arch207_idle_mode:
@@ -668,7 +669,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_HVMODE)
mtcr r6
mtspr SPRN_SRR1,r4
mtspr SPRN_SRR0,r5
- rfid
+ RFI_TO_KERNEL
/*
* R3 here contains the value that will be returned to the caller
@@ -689,4 +690,4 @@ END_FTR_SECTION_IFSET(CPU_FTR_HVMODE)
mtcr r6
mtspr SPRN_SRR1,r4
mtspr SPRN_SRR0,r5
- rfid
+ RFI_TO_KERNEL
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index 0447a22a4df6..55fbc0c78721 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -65,7 +65,7 @@ _GLOBAL_TOC(kvmppc_hv_entry_trampoline)
mtmsrd r0,1 /* clear RI in MSR */
mtsrr0 r5
mtsrr1 r6
- RFI
+ RFI_TO_KERNEL
kvmppc_call_hv_entry:
ld r4, HSTATE_KVM_VCPU(r13)
@@ -171,7 +171,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
mtsrr0 r8
mtsrr1 r7
beq cr1, 13f /* machine check */
- RFI
+ RFI_TO_KERNEL
/* On POWER7, we have external interrupts set to use HSRR0/1 */
11: mtspr SPRN_HSRR0, r8
@@ -1018,8 +1018,7 @@ BEGIN_FTR_SECTION
END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
ld r0, VCPU_GPR(R0)(r4)
ld r4, VCPU_GPR(R4)(r4)
-
- hrfid
+ HRFI_TO_GUEST
b .
secondary_too_late:
diff --git a/arch/powerpc/kvm/book3s_rmhandlers.S b/arch/powerpc/kvm/book3s_rmhandlers.S
index 42a4b237df5f..34a5adeff084 100644
--- a/arch/powerpc/kvm/book3s_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_rmhandlers.S
@@ -46,6 +46,9 @@
#define FUNC(name) name
+#define RFI_TO_KERNEL RFI
+#define RFI_TO_GUEST RFI
+
.macro INTERRUPT_TRAMPOLINE intno
.global kvmppc_trampoline_\intno
@@ -141,7 +144,7 @@ kvmppc_handler_skip_ins:
GET_SCRATCH0(r13)
/* And get back into the code */
- RFI
+ RFI_TO_KERNEL
#endif
/*
@@ -164,6 +167,6 @@ _GLOBAL_TOC(kvmppc_entry_trampoline)
ori r5, r5, MSR_EE
mtsrr0 r7
mtsrr1 r6
- RFI
+ RFI_TO_KERNEL
#include "book3s_segment.S"
diff --git a/arch/powerpc/kvm/book3s_segment.S b/arch/powerpc/kvm/book3s_segment.S
index ca8f174289bb..7c982956d709 100644
--- a/arch/powerpc/kvm/book3s_segment.S
+++ b/arch/powerpc/kvm/book3s_segment.S
@@ -156,7 +156,7 @@ no_dcbz32_on:
PPC_LL r9, SVCPU_R9(r3)
PPC_LL r3, (SVCPU_R3)(r3)
- RFI
+ RFI_TO_GUEST
kvmppc_handler_trampoline_enter_end:
@@ -389,5 +389,5 @@ END_FTR_SECTION_IFSET(CPU_FTR_HVMODE)
cmpwi r12, BOOK3S_INTERRUPT_DOORBELL
beqa BOOK3S_INTERRUPT_DOORBELL
- RFI
+ RFI_TO_KERNEL
kvmppc_handler_trampoline_exit_end:
--
2.14.1
^ permalink raw reply related
* [PATCH v4.4 backport 3/3] powerpc/64s: Improve RFI L1-D cache flush fallback
From: Michael Ellerman @ 2018-02-22 12:35 UTC (permalink / raw)
To: stable, greg; +Cc: npiggin, linuxppc-dev, linux, corsac
In-Reply-To: <20180222123545.8946-1-mpe@ellerman.id.au>
From: Nicholas Piggin <npiggin@gmail.com>
commit bdcb1aefc5b3f7d0f1dc8b02673602bca2ff7a4b upstream.
The fallback RFI flush is used when firmware does not provide a way
to flush the cache. It's a "displacement flush" that evicts useful
data by displacing it with an uninteresting buffer.
The flush has to take care to work with implementation specific cache
replacment policies, so the recipe has been in flux. The initial
slow but conservative approach is to touch all lines of a congruence
class, with dependencies between each load. It has since been
determined that a linear pattern of loads without dependencies is
sufficient, and is significantly faster.
Measuring the speed of a null syscall with RFI fallback flush enabled
gives the relative improvement:
P8 - 1.83x
P9 - 1.75x
The flush also becomes simpler and more adaptable to different cache
geometries.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
[mpe: Backport to 4.9]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/paca.h | 3 +-
arch/powerpc/kernel/asm-offsets.c | 3 +-
arch/powerpc/kernel/exceptions-64s.S | 76 +++++++++++++++++-------------------
arch/powerpc/kernel/setup_64.c | 13 +-----
4 files changed, 39 insertions(+), 56 deletions(-)
diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index ea43897183fd..c75ee2d886fc 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -212,8 +212,7 @@ struct paca_struct {
*/
u64 exrfi[13] __aligned(0x80);
void *rfi_flush_fallback_area;
- u64 l1d_flush_congruence;
- u64 l1d_flush_sets;
+ u64 l1d_flush_size;
#endif
};
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index 64bcbd580495..14fbbd9035ca 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -242,8 +242,7 @@ int main(void)
DEFINE(PACA_IN_MCE, offsetof(struct paca_struct, in_mce));
DEFINE(PACA_RFI_FLUSH_FALLBACK_AREA, offsetof(struct paca_struct, rfi_flush_fallback_area));
DEFINE(PACA_EXRFI, offsetof(struct paca_struct, exrfi));
- DEFINE(PACA_L1D_FLUSH_CONGRUENCE, offsetof(struct paca_struct, l1d_flush_congruence));
- DEFINE(PACA_L1D_FLUSH_SETS, offsetof(struct paca_struct, l1d_flush_sets));
+ DEFINE(PACA_L1D_FLUSH_SIZE, offsetof(struct paca_struct, l1d_flush_size));
#endif
DEFINE(PACAHWCPUID, offsetof(struct paca_struct, hw_cpu_id));
DEFINE(PACAKEXECSTATE, offsetof(struct paca_struct, kexec_state));
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index 29892500e646..7614d1dd2c0b 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -1602,39 +1602,37 @@ rfi_flush_fallback:
std r9,PACA_EXRFI+EX_R9(r13)
std r10,PACA_EXRFI+EX_R10(r13)
std r11,PACA_EXRFI+EX_R11(r13)
- std r12,PACA_EXRFI+EX_R12(r13)
- std r8,PACA_EXRFI+EX_R13(r13)
mfctr r9
ld r10,PACA_RFI_FLUSH_FALLBACK_AREA(r13)
- ld r11,PACA_L1D_FLUSH_SETS(r13)
- ld r12,PACA_L1D_FLUSH_CONGRUENCE(r13)
- /*
- * The load adresses are at staggered offsets within cachelines,
- * which suits some pipelines better (on others it should not
- * hurt).
- */
- addi r12,r12,8
+ ld r11,PACA_L1D_FLUSH_SIZE(r13)
+ srdi r11,r11,(7 + 3) /* 128 byte lines, unrolled 8x */
mtctr r11
DCBT_STOP_ALL_STREAM_IDS(r11) /* Stop prefetch streams */
/* order ld/st prior to dcbt stop all streams with flushing */
sync
-1: li r8,0
- .rept 8 /* 8-way set associative */
- ldx r11,r10,r8
- add r8,r8,r12
- xor r11,r11,r11 // Ensure r11 is 0 even if fallback area is not
- add r8,r8,r11 // Add 0, this creates a dependency on the ldx
- .endr
- addi r10,r10,128 /* 128 byte cache line */
+
+ /*
+ * The load adresses are at staggered offsets within cachelines,
+ * which suits some pipelines better (on others it should not
+ * hurt).
+ */
+1:
+ ld r11,(0x80 + 8)*0(r10)
+ ld r11,(0x80 + 8)*1(r10)
+ ld r11,(0x80 + 8)*2(r10)
+ ld r11,(0x80 + 8)*3(r10)
+ ld r11,(0x80 + 8)*4(r10)
+ ld r11,(0x80 + 8)*5(r10)
+ ld r11,(0x80 + 8)*6(r10)
+ ld r11,(0x80 + 8)*7(r10)
+ addi r10,r10,0x80*8
bdnz 1b
mtctr r9
ld r9,PACA_EXRFI+EX_R9(r13)
ld r10,PACA_EXRFI+EX_R10(r13)
ld r11,PACA_EXRFI+EX_R11(r13)
- ld r12,PACA_EXRFI+EX_R12(r13)
- ld r8,PACA_EXRFI+EX_R13(r13)
GET_SCRATCH0(r13);
rfid
@@ -1645,39 +1643,37 @@ hrfi_flush_fallback:
std r9,PACA_EXRFI+EX_R9(r13)
std r10,PACA_EXRFI+EX_R10(r13)
std r11,PACA_EXRFI+EX_R11(r13)
- std r12,PACA_EXRFI+EX_R12(r13)
- std r8,PACA_EXRFI+EX_R13(r13)
mfctr r9
ld r10,PACA_RFI_FLUSH_FALLBACK_AREA(r13)
- ld r11,PACA_L1D_FLUSH_SETS(r13)
- ld r12,PACA_L1D_FLUSH_CONGRUENCE(r13)
- /*
- * The load adresses are at staggered offsets within cachelines,
- * which suits some pipelines better (on others it should not
- * hurt).
- */
- addi r12,r12,8
+ ld r11,PACA_L1D_FLUSH_SIZE(r13)
+ srdi r11,r11,(7 + 3) /* 128 byte lines, unrolled 8x */
mtctr r11
DCBT_STOP_ALL_STREAM_IDS(r11) /* Stop prefetch streams */
/* order ld/st prior to dcbt stop all streams with flushing */
sync
-1: li r8,0
- .rept 8 /* 8-way set associative */
- ldx r11,r10,r8
- add r8,r8,r12
- xor r11,r11,r11 // Ensure r11 is 0 even if fallback area is not
- add r8,r8,r11 // Add 0, this creates a dependency on the ldx
- .endr
- addi r10,r10,128 /* 128 byte cache line */
+
+ /*
+ * The load adresses are at staggered offsets within cachelines,
+ * which suits some pipelines better (on others it should not
+ * hurt).
+ */
+1:
+ ld r11,(0x80 + 8)*0(r10)
+ ld r11,(0x80 + 8)*1(r10)
+ ld r11,(0x80 + 8)*2(r10)
+ ld r11,(0x80 + 8)*3(r10)
+ ld r11,(0x80 + 8)*4(r10)
+ ld r11,(0x80 + 8)*5(r10)
+ ld r11,(0x80 + 8)*6(r10)
+ ld r11,(0x80 + 8)*7(r10)
+ addi r10,r10,0x80*8
bdnz 1b
mtctr r9
ld r9,PACA_EXRFI+EX_R9(r13)
ld r10,PACA_EXRFI+EX_R10(r13)
ld r11,PACA_EXRFI+EX_R11(r13)
- ld r12,PACA_EXRFI+EX_R12(r13)
- ld r8,PACA_EXRFI+EX_R13(r13)
GET_SCRATCH0(r13);
hrfid
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 7c30a91c1f86..5243501d95ef 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -745,19 +745,8 @@ static void init_fallback_flush(void)
memset(l1d_flush_fallback_area, 0, l1d_size * 2);
for_each_possible_cpu(cpu) {
- /*
- * The fallback flush is currently coded for 8-way
- * associativity. Different associativity is possible, but it
- * will be treated as 8-way and may not evict the lines as
- * effectively.
- *
- * 128 byte lines are mandatory.
- */
- u64 c = l1d_size / 8;
-
paca[cpu].rfi_flush_fallback_area = l1d_flush_fallback_area;
- paca[cpu].l1d_flush_congruence = c;
- paca[cpu].l1d_flush_sets = c / 128;
+ paca[cpu].l1d_flush_size = l1d_size;
}
}
--
2.14.1
^ permalink raw reply related
* [PATCH v4.9 backport 1/3] powerpc/64s: Fix conversion of slb_miss_common to use RFI_TO_USER/KERNEL
From: Michael Ellerman @ 2018-02-22 12:35 UTC (permalink / raw)
To: stable, greg; +Cc: npiggin, linuxppc-dev, linux, corsac
In-Reply-To: <20180222065738.GB2428@kroah.com>
The back port of commit c7305645eb0c ("powerpc/64s: Convert
slb_miss_common to use RFI_TO_USER/KERNEL") missed a hunk needed to
restore cr6.
Fixes: 48cc95d4e4d6 ("powerpc/64s: Convert slb_miss_common to use RFI_TO_USER/KERNEL")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/kernel/exceptions-64s.S | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index 96db6c3adebe..d0be752ea86c 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -680,6 +680,7 @@ END_MMU_FTR_SECTION_IFCLR(MMU_FTR_TYPE_RADIX)
.machine push
.machine "power4"
mtcrf 0x80,r9
+ mtcrf 0x02,r9 /* I/D indication is in cr6 */
mtcrf 0x01,r9 /* slb_allocate uses cr0 and cr7 */
.machine pop
--
2.14.1
^ permalink raw reply related
* Re: [PATCH] PCI/AER: Add a null check before eeh_ops->notify_resume callback.
From: Vaibhav Jain @ 2018-02-22 12:31 UTC (permalink / raw)
To: Russell Currey, Michael Ellerman
Cc: Frederic Barrat, linuxppc-dev, Benjamin Herrenschmidt,
Bryant G . Ly
In-Reply-To: <20180222115803.21738-1-vaibhav@linux.vnet.ibm.com>
There is already a patch for this issue applied to ppc-next viz commit
521ca5a9859a870e354d1a6b84a6ff ("powerpc/eeh: Add conditional check on
notify_resume"). So please ignore the patch.
--
Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Linux Technology Center, IBM India Pvt. Ltd.
^ permalink raw reply
* Re: [PATCH 16/18] crypto: talitos - do hw_context DMA mapping outside the requests
From: Horia Geantă @ 2018-02-22 12:29 UTC (permalink / raw)
To: Herbert Xu, Christophe LEROY
Cc: David S. Miller, linux-crypto@vger.kernel.org,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20180222114741.GA27631@gondor.apana.org.au>
On 2/22/2018 1:47 PM, Herbert Xu wrote:=0A=
> On Tue, Feb 20, 2018 at 11:32:25AM +0000, Horia Geant=E3 wrote:=0A=
>>=0A=
>> If final/finup is optional, how is the final hash supposed to be retriev=
ed?=0A=
> =0A=
> Sometimes the computation ends with a partial hash, that's what=0A=
> export is for. Also it is completely legal to abandon the hash=0A=
> state entirely.=0A=
> =0A=
Thanks for the explanation.=0A=
It's unintuitive to call .init() -> .update() and then not to call any of=
=0A=
.final(), .finup(), .export().=0A=
=0A=
Christophe,=0A=
=0A=
IIUC this means that there is no room for improvement.=0A=
This patch needs to be reverted, to restore previous behaviour when the=0A=
hw_context was mapped / unmapped for every request.=0A=
=0A=
Thanks,=0A=
Horia=0A=
^ permalink raw reply
* [PATCH 5/5] powerpc/mm/32: Remove the reserved memory hack
From: Jonathan Neuschäfer @ 2018-02-22 12:15 UTC (permalink / raw)
To: linuxppc-dev
Cc: linux-kernel, Michael Ellerman, linux-mm, Joel Stanley,
Christophe LEROY, Jonathan Neuschäfer,
Benjamin Herrenschmidt, Paul Mackerras, Aneesh Kumar K.V,
Balbir Singh, Guenter Roeck
In-Reply-To: <20180222121516.23415-1-j.neuschaefer@gmx.net>
This hack, introduced in commit c5df7f775148 ("powerpc: allow ioremap
within reserved memory regions") is now unnecessary.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---
arch/powerpc/mm/init_32.c | 5 -----
arch/powerpc/mm/mmu_decl.h | 1 -
arch/powerpc/mm/pgtable_32.c | 3 +--
3 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index 6419b33ca309..326240177fa6 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -88,11 +88,6 @@ void MMU_init(void);
int __map_without_bats;
int __map_without_ltlbs;
-/*
- * This tells the system to allow ioremapping memory marked as reserved.
- */
-int __allow_ioremap_reserved;
-
/* max amount of low RAM to map in */
unsigned long __max_low_memory = MAX_LOW_MEM;
diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
index 57fbc554c785..c4c0a09a7775 100644
--- a/arch/powerpc/mm/mmu_decl.h
+++ b/arch/powerpc/mm/mmu_decl.h
@@ -98,7 +98,6 @@ extern void setbat(int index, unsigned long virt, phys_addr_t phys,
unsigned int size, pgprot_t prot);
extern int __map_without_bats;
-extern int __allow_ioremap_reserved;
extern unsigned int rtas_data, rtas_size;
struct hash_pte;
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index d54e1a9c1c99..a89eb3b898cd 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -146,8 +146,7 @@ __ioremap_caller(phys_addr_t addr, unsigned long size, unsigned long flags,
/*
* Don't allow anybody to remap normal RAM that we're using.
*/
- if (page_is_ram(__phys_to_pfn(p)) &&
- !(__allow_ioremap_reserved && memblock_is_region_reserved(p, size))) {
+ if (page_is_ram(__phys_to_pfn(p))) {
printk("__ioremap(): phys addr 0x%llx is RAM lr %ps\n",
(unsigned long long)p, __builtin_return_address(0));
return NULL;
--
2.16.1
^ permalink raw reply related
* [PATCH 3/5] powerpc/mm/32: Use page_is_ram to check for RAM
From: Jonathan Neuschäfer @ 2018-02-22 12:15 UTC (permalink / raw)
To: linuxppc-dev
Cc: linux-kernel, Michael Ellerman, linux-mm, Joel Stanley,
Christophe LEROY, Jonathan Neuschäfer,
Benjamin Herrenschmidt, Paul Mackerras, Balbir Singh,
Guenter Roeck
In-Reply-To: <20180222121516.23415-1-j.neuschaefer@gmx.net>
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---
arch/powerpc/mm/pgtable_32.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index d35d9ad3c1cd..d54e1a9c1c99 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -145,9 +145,8 @@ __ioremap_caller(phys_addr_t addr, unsigned long size, unsigned long flags,
#ifndef CONFIG_CRASH_DUMP
/*
* Don't allow anybody to remap normal RAM that we're using.
- * mem_init() sets high_memory so only do the check after that.
*/
- if (slab_is_available() && (p < virt_to_phys(high_memory)) &&
+ if (page_is_ram(__phys_to_pfn(p)) &&
!(__allow_ioremap_reserved && memblock_is_region_reserved(p, size))) {
printk("__ioremap(): phys addr 0x%llx is RAM lr %ps\n",
(unsigned long long)p, __builtin_return_address(0));
--
2.16.1
^ permalink raw reply related
* Re: [PATCH v3 2/2] ocxl: Document the OCXL_IOCTL_GET_METADATA IOCTL
From: Frederic Barrat @ 2018-02-22 12:16 UTC (permalink / raw)
To: Alastair D'Silva, linuxppc-dev, linux-kernel
Cc: arnd, frederic.barrat, gregkh, andrew.donnellan,
Alastair D'Silva
In-Reply-To: <20180222041739.27899-3-alastair@au1.ibm.com>
Le 22/02/2018 à 05:17, Alastair D'Silva a écrit :
> From: Alastair D'Silva <alastair@d-silva.org>
>
> Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
> ---
Acked-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
> Documentation/accelerators/ocxl.rst | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/accelerators/ocxl.rst b/Documentation/accelerators/ocxl.rst
> index 4f7af841d935..ddcc58d01cfb 100644
> --- a/Documentation/accelerators/ocxl.rst
> +++ b/Documentation/accelerators/ocxl.rst
> @@ -152,6 +152,11 @@ OCXL_IOCTL_IRQ_SET_FD:
> Associate an event fd to an AFU interrupt so that the user process
> can be notified when the AFU sends an interrupt.
>
> +OCXL_IOCTL_GET_METADATA:
> +
> + Obtains configuration information from the card, such at the size of
> + MMIO areas, the AFU version, and the PASID for the current context.
> +
>
> mmap
> ----
>
^ permalink raw reply
* Re: [PATCH v3 1/2] ocxl: Add get_metadata IOCTL to share OCXL information to userspace
From: Frederic Barrat @ 2018-02-22 12:16 UTC (permalink / raw)
To: Alastair D'Silva, linuxppc-dev, linux-kernel
Cc: arnd, frederic.barrat, gregkh, andrew.donnellan,
Alastair D'Silva
In-Reply-To: <20180222041739.27899-2-alastair@au1.ibm.com>
Le 22/02/2018 à 05:17, Alastair D'Silva a écrit :
> From: Alastair D'Silva <alastair@d-silva.org>
>
> Some required information is not exposed to userspace currently (eg. the
> PASID), pass this information back, along with other information which
> is currently communicated via sysfs, which saves some parsing effort in
> userspace.
>
> Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
> ---
Thanks!
Acked-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
> drivers/misc/ocxl/file.c | 27 +++++++++++++++++++++++++++
> include/uapi/misc/ocxl.h | 17 +++++++++++++++++
> 2 files changed, 44 insertions(+)
>
> diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c
> index d9aa407db06a..90df1be5ef3f 100644
> --- a/drivers/misc/ocxl/file.c
> +++ b/drivers/misc/ocxl/file.c
> @@ -102,10 +102,32 @@ static long afu_ioctl_attach(struct ocxl_context *ctx,
> return rc;
> }
>
> +static long afu_ioctl_get_metadata(struct ocxl_context *ctx,
> + struct ocxl_ioctl_metadata __user *uarg)
> +{
> + struct ocxl_ioctl_metadata arg;
> +
> + memset(&arg, 0, sizeof(arg));
> +
> + arg.version = 0;
> +
> + arg.afu_version_major = ctx->afu->config.version_major;
> + arg.afu_version_minor = ctx->afu->config.version_minor;
> + arg.pasid = ctx->pasid;
> + arg.pp_mmio_size = ctx->afu->config.pp_mmio_stride;
> + arg.global_mmio_size = ctx->afu->config.global_mmio_size;
> +
> + if (copy_to_user(uarg, &arg, sizeof(arg)))
> + return -EFAULT;
> +
> + return 0;
> +}
> +
> #define CMD_STR(x) (x == OCXL_IOCTL_ATTACH ? "ATTACH" : \
> x == OCXL_IOCTL_IRQ_ALLOC ? "IRQ_ALLOC" : \
> x == OCXL_IOCTL_IRQ_FREE ? "IRQ_FREE" : \
> x == OCXL_IOCTL_IRQ_SET_FD ? "IRQ_SET_FD" : \
> + x == OCXL_IOCTL_GET_METADATA ? "GET_METADATA" : \
> "UNKNOWN")
>
> static long afu_ioctl(struct file *file, unsigned int cmd,
> @@ -157,6 +179,11 @@ static long afu_ioctl(struct file *file, unsigned int cmd,
> irq_fd.eventfd);
> break;
>
> + case OCXL_IOCTL_GET_METADATA:
> + rc = afu_ioctl_get_metadata(ctx,
> + (struct ocxl_ioctl_metadata __user *) args);
> + break;
> +
> default:
> rc = -EINVAL;
> }
> diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h
> index 4b0b0b756f3e..0af83d80fb3e 100644
> --- a/include/uapi/misc/ocxl.h
> +++ b/include/uapi/misc/ocxl.h
> @@ -32,6 +32,22 @@ struct ocxl_ioctl_attach {
> __u64 reserved3;
> };
>
> +struct ocxl_ioctl_metadata {
> + __u16 version; // struct version, always backwards compatible
> +
> + // Version 0 fields
> + __u8 afu_version_major;
> + __u8 afu_version_minor;
> + __u32 pasid; // PASID assigned to the current context
> +
> + __u64 pp_mmio_size; // Per PASID MMIO size
> + __u64 global_mmio_size;
> +
> + // End version 0 fields
> +
> + __u64 reserved[13]; // Total of 16*u64
> +};
> +
> struct ocxl_ioctl_irq_fd {
> __u64 irq_offset;
> __s32 eventfd;
> @@ -45,5 +61,6 @@ struct ocxl_ioctl_irq_fd {
> #define OCXL_IOCTL_IRQ_ALLOC _IOR(OCXL_MAGIC, 0x11, __u64)
> #define OCXL_IOCTL_IRQ_FREE _IOW(OCXL_MAGIC, 0x12, __u64)
> #define OCXL_IOCTL_IRQ_SET_FD _IOW(OCXL_MAGIC, 0x13, struct ocxl_ioctl_irq_fd)
> +#define OCXL_IOCTL_GET_METADATA _IOR(OCXL_MAGIC, 0x14, struct ocxl_ioctl_metadata)
>
> #endif /* _UAPI_MISC_OCXL_H */
>
^ permalink raw reply
* [PATCH 4/5] powerpc: wii: Don't rely on the reserved memory hack
From: Jonathan Neuschäfer @ 2018-02-22 12:15 UTC (permalink / raw)
To: linuxppc-dev
Cc: linux-kernel, Michael Ellerman, linux-mm, Joel Stanley,
Christophe LEROY, Jonathan Neuschäfer,
Benjamin Herrenschmidt, Paul Mackerras
In-Reply-To: <20180222121516.23415-1-j.neuschaefer@gmx.net>
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---
arch/powerpc/platforms/embedded6xx/wii.c | 14 +-------------
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/arch/powerpc/platforms/embedded6xx/wii.c b/arch/powerpc/platforms/embedded6xx/wii.c
index 4682327f76a9..fc00d82691e1 100644
--- a/arch/powerpc/platforms/embedded6xx/wii.c
+++ b/arch/powerpc/platforms/embedded6xx/wii.c
@@ -81,21 +81,9 @@ void __init wii_memory_fixups(void)
BUG_ON(memblock.memory.cnt != 2);
BUG_ON(!page_aligned(p[0].base) || !page_aligned(p[1].base));
- /* trim unaligned tail */
- memblock_remove(ALIGN(p[1].base + p[1].size, PAGE_SIZE),
- (phys_addr_t)ULLONG_MAX);
-
- /* determine hole, add & reserve them */
+ /* determine hole */
wii_hole_start = ALIGN(p[0].base + p[0].size, PAGE_SIZE);
wii_hole_size = p[1].base - wii_hole_start;
- memblock_add(wii_hole_start, wii_hole_size);
- memblock_reserve(wii_hole_start, wii_hole_size);
-
- BUG_ON(memblock.memory.cnt != 1);
- __memblock_dump_all();
-
- /* allow ioremapping the address space in the hole */
- __allow_ioremap_reserved = 1;
}
unsigned long __init wii_mmu_mapin_mem2(unsigned long top)
--
2.16.1
^ permalink raw reply related
* [PATCH 2/5] powerpc: mm: Use memblock API for PPC32 page_is_ram
From: Jonathan Neuschäfer @ 2018-02-22 12:15 UTC (permalink / raw)
To: linuxppc-dev
Cc: linux-kernel, Michael Ellerman, linux-mm, Joel Stanley,
Christophe LEROY, Jonathan Neuschäfer,
Benjamin Herrenschmidt, Paul Mackerras, Vlastimil Babka,
Michal Hocko, Andrew Morton, Balbir Singh, Oliver O'Halloran,
Joe Perches
In-Reply-To: <20180222121516.23415-1-j.neuschaefer@gmx.net>
To support accurate checking for different blocks of memory on PPC32,
use the same memblock-based approach that's already used on PPC64 also
on PPC32.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---
arch/powerpc/mm/mem.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index da4e1555d61d..a42b86e2a34c 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -82,11 +82,7 @@ static inline pte_t *virt_to_kpte(unsigned long vaddr)
int page_is_ram(unsigned long pfn)
{
-#ifndef CONFIG_PPC64 /* XXX for now */
- return pfn < max_pfn;
-#else
return memblock_is_memory(__pfn_to_phys(pfn));
-#endif
}
pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
--
2.16.1
^ permalink raw reply related
* [PATCH 1/5] powerpc: mm: Simplify page_is_ram by using memblock_is_memory
From: Jonathan Neuschäfer @ 2018-02-22 12:15 UTC (permalink / raw)
To: linuxppc-dev
Cc: linux-kernel, Michael Ellerman, linux-mm, Joel Stanley,
Christophe LEROY, Jonathan Neuschäfer,
Benjamin Herrenschmidt, Paul Mackerras, Vlastimil Babka,
Michal Hocko, Andrew Morton, Balbir Singh, Joe Perches,
Oliver O'Halloran
In-Reply-To: <20180222121516.23415-1-j.neuschaefer@gmx.net>
Instead of open-coding the search in page_is_ram, call memblock_is_memory.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---
arch/powerpc/mm/mem.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index fe8c61149fb8..da4e1555d61d 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -85,13 +85,7 @@ int page_is_ram(unsigned long pfn)
#ifndef CONFIG_PPC64 /* XXX for now */
return pfn < max_pfn;
#else
- unsigned long paddr = (pfn << PAGE_SHIFT);
- struct memblock_region *reg;
-
- for_each_memblock(memory, reg)
- if (paddr >= reg->base && paddr < (reg->base + reg->size))
- return 1;
- return 0;
+ return memblock_is_memory(__pfn_to_phys(pfn));
#endif
}
--
2.16.1
^ permalink raw reply related
* [PATCH 0/5] PPC32/ioremap: Use memblock API to check for RAM
From: Jonathan Neuschäfer @ 2018-02-22 12:15 UTC (permalink / raw)
To: linuxppc-dev
Cc: linux-kernel, Michael Ellerman, linux-mm, Joel Stanley,
Christophe LEROY, Jonathan Neuschäfer
This patchset solves the same problem as my previous one[1] but follows
a rather different approach. Instead of implementing DISCONTIGMEM for
PowerPC32, I simply switched the "is this RAM" check in __ioremap_caller
to the existing page_is_ram function, and unified page_is_ram to search
memblock.memory on PPC64 and PPC32.
The intended result is, as before, that my Wii can allocate the MMIO
range of its GPIO controller, which was previously not possible, because
the reserved memory hack (__allow_ioremap_reserved) didn't affect the
API in kernel/resource.c.
Thanks to Christophe Leroy for reviewing the previous patchset.
[1]: https://www.spinics.net/lists/kernel/msg2726786.html
Jonathan Neuschäfer (5):
powerpc: mm: Simplify page_is_ram by using memblock_is_memory
powerpc: mm: Use memblock API for PPC32 page_is_ram
powerpc/mm/32: Use page_is_ram to check for RAM
powerpc: wii: Don't rely on the reserved memory hack
powerpc/mm/32: Remove the reserved memory hack
arch/powerpc/mm/init_32.c | 5 -----
arch/powerpc/mm/mem.c | 12 +-----------
arch/powerpc/mm/mmu_decl.h | 1 -
arch/powerpc/mm/pgtable_32.c | 4 +---
arch/powerpc/platforms/embedded6xx/wii.c | 14 +-------------
5 files changed, 3 insertions(+), 33 deletions(-)
--
2.16.1
^ permalink raw reply
* Re: [RFC][PATCH bpf v2 1/2] bpf: allow 64-bit offsets for bpf function calls
From: Michael Holzheu @ 2018-02-22 12:10 UTC (permalink / raw)
To: Martin Schwidefsky
Cc: Michael Holzheu, Naveen N. Rao, ast, Daniel Borkmann,
Sandipan Das, Michael Ellerman, linuxppc-dev, netdev
In-Reply-To: <20180222130640.0043c8d3@TP-holzheu>
Am Thu, 22 Feb 2018 13:06:40 +0100
schrieb Michael Holzheu <holzheu@linux.vnet.ibm.com>:
> Am Fri, 16 Feb 2018 21:20:09 +0530
> schrieb "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>:
>
> > Daniel Borkmann wrote:
> > > On 02/15/2018 05:25 PM, Daniel Borkmann wrote:
> > >> On 02/13/2018 05:05 AM, Sandipan Das wrote:
> > >>> The imm field of a bpf_insn is a signed 32-bit integer. For
> > >>> JIT-ed bpf-to-bpf function calls, it stores the offset from
> > >>> __bpf_call_base to the start of the callee function.
> > >>>
> > >>> For some architectures, such as powerpc64, it was found that
> > >>> this offset may be as large as 64 bits because of which this
> > >>> cannot be accomodated in the imm field without truncation.
> > >>>
> > >>> To resolve this, we additionally make aux->func within each
> > >>> bpf_prog associated with the functions to point to the list
> > >>> of all function addresses determined by the verifier.
> > >>>
> > >>> We keep the value assigned to the off field of the bpf_insn
> > >>> as a way to index into aux->func and also set aux->func_cnt
> > >>> so that this can be used for performing basic upper bound
> > >>> checks for the off field.
> > >>>
> > >>> Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>
> > >>> ---
> > >>> v2: Make aux->func point to the list of functions determined
> > >>> by the verifier rather than allocating a separate callee
> > >>> list for each function.
> > >>
> > >> Approach looks good to me; do you know whether s390x JIT would
> > >> have similar requirement? I think one limitation that would still
> > >> need to be addressed later with such approach would be regarding the
> > >> xlated prog dump in bpftool, see 'BPF calls via JIT' in 7105e828c087
> > >> ("bpf: allow for correlation of maps and helpers in dump"). Any
> > >> ideas for this (potentially if we could use off + imm for calls,
> > >> we'd get to 48 bits, but that seems still not be enough as you say)?
> >
> > All good points. I'm not really sure how s390x works, so I can't comment
> > on that, but I'm copying Michael Holzheu for his consideration.
> >
> > With the existing scheme, 48 bits won't be enough, so we rejected that
> > approach. I can also see how this will be a problem with bpftool, but I
> > haven't looked into it in detail. I wonder if we can annotate the output
> > to indicate the function being referred to?
> >
> > >
> > > One other random thought, although I'm not sure how feasible this
> > > is for ppc64 JIT to realize ... but idea would be to have something
> > > like the below:
> > >
> > > diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> > > index 29ca920..daa7258 100644
> > > --- a/kernel/bpf/core.c
> > > +++ b/kernel/bpf/core.c
> > > @@ -512,6 +512,11 @@ int bpf_get_kallsym(unsigned int symnum, unsigned long *value, char *type,
> > > return ret;
> > > }
> > >
> > > +void * __weak bpf_jit_image_alloc(unsigned long size)
> > > +{
> > > + return module_alloc(size);
> > > +}
> > > +
> > > struct bpf_binary_header *
> > > bpf_jit_binary_alloc(unsigned int proglen, u8 **image_ptr,
> > > unsigned int alignment,
> > > @@ -525,7 +530,7 @@ bpf_jit_binary_alloc(unsigned int proglen, u8 **image_ptr,
> > > * random section of illegal instructions.
> > > */
> > > size = round_up(proglen + sizeof(*hdr) + 128, PAGE_SIZE);
> > > - hdr = module_alloc(size);
> > > + hdr = bpf_jit_image_alloc(size);
> > > if (hdr == NULL)
> > > return NULL;
> > >
> > > And ppc64 JIT could override bpf_jit_image_alloc() in a similar way
> > > like some archs would override the module_alloc() helper through a
> > > custom implementation, usually via __vmalloc_node_range(), so we
> > > could perhaps fit the range for BPF JITed images in a way that they
> > > could use the 32bit imm in the end? There are not that many progs
> > > loaded typically, so the range could be a bit narrower in such case
> > > anyway. (Not sure if this would work out though, but I thought to
> > > bring it up.)
> >
> > That'd be a good option to consider. I don't think we want to allocate
> > anything from the linear memory range since users could load
> > unprivileged BPF programs and consume a lot of memory that way. I doubt
> > if we can map vmalloc'ed memory into the 0xc0 address range, but I'm not
> > entirely sure.
> >
> > Michael,
> > Is the above possible? The question is if we can have BPF programs be
> > allocated within 4GB of __bpf_call_base (which is a kernel symbol), so
> > that calls to those programs can be encoded in a 32-bit immediate field
> > in a BPF instruction. As an extension, we may be able to extend it to
> > 48-bits by combining with another BPF instruction field (offset). In
> > either case, the vmalloc'ed address range won't work.
> >
> > The alternative is to pass the full 64-bit address of the BPF program in
> > an auxiliary field (as proposed in this patch set) but we need to fix it
> > up for 'bpftool' as well.
> Hi Naveen,
>
> Our s390 kernel maintainer Martin Schwidefsky took over
> eBPF responsibility for s390 from me.
>
> @Martin: Can you answer Navee's question?
>
> Michael
Damn, I forgot adding Martin to cc.
Time for vacation ;-)
Michael
^ permalink raw reply
* Re: [RFC][PATCH bpf v2 1/2] bpf: allow 64-bit offsets for bpf function calls
From: Michael Holzheu @ 2018-02-22 12:06 UTC (permalink / raw)
To: Naveen N. Rao
Cc: ast, Daniel Borkmann, Sandipan Das, Michael Ellerman,
linuxppc-dev, netdev
In-Reply-To: <1518791626.5484j97if6.naveen@linux.ibm.com>
Am Fri, 16 Feb 2018 21:20:09 +0530
schrieb "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>:
> Daniel Borkmann wrote:
> > On 02/15/2018 05:25 PM, Daniel Borkmann wrote:
> >> On 02/13/2018 05:05 AM, Sandipan Das wrote:
> >>> The imm field of a bpf_insn is a signed 32-bit integer. For
> >>> JIT-ed bpf-to-bpf function calls, it stores the offset from
> >>> __bpf_call_base to the start of the callee function.
> >>>
> >>> For some architectures, such as powerpc64, it was found that
> >>> this offset may be as large as 64 bits because of which this
> >>> cannot be accomodated in the imm field without truncation.
> >>>
> >>> To resolve this, we additionally make aux->func within each
> >>> bpf_prog associated with the functions to point to the list
> >>> of all function addresses determined by the verifier.
> >>>
> >>> We keep the value assigned to the off field of the bpf_insn
> >>> as a way to index into aux->func and also set aux->func_cnt
> >>> so that this can be used for performing basic upper bound
> >>> checks for the off field.
> >>>
> >>> Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>
> >>> ---
> >>> v2: Make aux->func point to the list of functions determined
> >>> by the verifier rather than allocating a separate callee
> >>> list for each function.
> >>
> >> Approach looks good to me; do you know whether s390x JIT would
> >> have similar requirement? I think one limitation that would still
> >> need to be addressed later with such approach would be regarding the
> >> xlated prog dump in bpftool, see 'BPF calls via JIT' in 7105e828c087
> >> ("bpf: allow for correlation of maps and helpers in dump"). Any
> >> ideas for this (potentially if we could use off + imm for calls,
> >> we'd get to 48 bits, but that seems still not be enough as you say)?
>
> All good points. I'm not really sure how s390x works, so I can't comment
> on that, but I'm copying Michael Holzheu for his consideration.
>
> With the existing scheme, 48 bits won't be enough, so we rejected that
> approach. I can also see how this will be a problem with bpftool, but I
> haven't looked into it in detail. I wonder if we can annotate the output
> to indicate the function being referred to?
>
> >
> > One other random thought, although I'm not sure how feasible this
> > is for ppc64 JIT to realize ... but idea would be to have something
> > like the below:
> >
> > diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> > index 29ca920..daa7258 100644
> > --- a/kernel/bpf/core.c
> > +++ b/kernel/bpf/core.c
> > @@ -512,6 +512,11 @@ int bpf_get_kallsym(unsigned int symnum, unsigned long *value, char *type,
> > return ret;
> > }
> >
> > +void * __weak bpf_jit_image_alloc(unsigned long size)
> > +{
> > + return module_alloc(size);
> > +}
> > +
> > struct bpf_binary_header *
> > bpf_jit_binary_alloc(unsigned int proglen, u8 **image_ptr,
> > unsigned int alignment,
> > @@ -525,7 +530,7 @@ bpf_jit_binary_alloc(unsigned int proglen, u8 **image_ptr,
> > * random section of illegal instructions.
> > */
> > size = round_up(proglen + sizeof(*hdr) + 128, PAGE_SIZE);
> > - hdr = module_alloc(size);
> > + hdr = bpf_jit_image_alloc(size);
> > if (hdr == NULL)
> > return NULL;
> >
> > And ppc64 JIT could override bpf_jit_image_alloc() in a similar way
> > like some archs would override the module_alloc() helper through a
> > custom implementation, usually via __vmalloc_node_range(), so we
> > could perhaps fit the range for BPF JITed images in a way that they
> > could use the 32bit imm in the end? There are not that many progs
> > loaded typically, so the range could be a bit narrower in such case
> > anyway. (Not sure if this would work out though, but I thought to
> > bring it up.)
>
> That'd be a good option to consider. I don't think we want to allocate
> anything from the linear memory range since users could load
> unprivileged BPF programs and consume a lot of memory that way. I doubt
> if we can map vmalloc'ed memory into the 0xc0 address range, but I'm not
> entirely sure.
>
> Michael,
> Is the above possible? The question is if we can have BPF programs be
> allocated within 4GB of __bpf_call_base (which is a kernel symbol), so
> that calls to those programs can be encoded in a 32-bit immediate field
> in a BPF instruction. As an extension, we may be able to extend it to
> 48-bits by combining with another BPF instruction field (offset). In
> either case, the vmalloc'ed address range won't work.
>
> The alternative is to pass the full 64-bit address of the BPF program in
> an auxiliary field (as proposed in this patch set) but we need to fix it
> up for 'bpftool' as well.
Hi Naveen,
Our s390 kernel maintainer Martin Schwidefsky took over
eBPF responsibility for s390 from me.
@Martin: Can you answer Navee's question?
Michael
^ permalink raw reply
* Re: [PATCH] ocxl: Add get_metadata IOCTL to share OCXL information to userspace
From: Frederic Barrat @ 2018-02-22 12:04 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <CAKTCnzkjbNVxBVTKmffbxsyqMb83y2tXN1Xv4Zm3VT+sxePdpg@mail.gmail.com>
>>> Yeah, I think metadata will evolve for a while till it settle's down.
>>> Since ocxl_ioctl_get_metadata is exposed via uapi, a newer program
>>> calling an older kernel will never work, since the size of that
>>> struct
>>> will always be larger than what the OS supports and our
>>> copy_to_user()
>>> will fail. The other option is for the user program to try all
>>> possible versions till one succeeds, that is bad as well. I think
>>> there are a few ways around it, if we care about this combination.
>>>
>>> Balbir Singh.
>>>
>>
>> We have a number of reserved members at the end of the struct which can
>> be re-purposed for future information (with a corresponding bump of the
>> version number).
>
> Good point, agreed
I initially had reservations about using an ioctl command for various
AFU/context parameters because extensibility is going to be a pain. With
the current reserved fields and versioning, we're ok for some time
(version handling will remain a bit of a pain but that's life). I agree
it helps the library by making things more light weight compared to
sysfs. But if we need to add parameters in the future, we should keep
sysfs as an option, especially if it's for rarely used parameters, i.e.
not something we'll need immediately after an open().
Fred
^ permalink raw reply
* [PATCH] PCI/AER: Add a null check before eeh_ops->notify_resume callback.
From: Vaibhav Jain @ 2018-02-22 11:58 UTC (permalink / raw)
To: Russell Currey, Michael Ellerman
Cc: Vaibhav Jain, Frederic Barrat, linuxppc-dev,
Benjamin Herrenschmidt, Bryant G . Ly
This patch puts a NULL check before branching to the address pointed
to by eeh_ops->notify_resume in eeh_report_resume(). The callback
is used to notify the arch EEH code that a pci device is back
online.
For PPC64 presently, only an implementation for pseries platform is
available and not for powernv. Hence without this patch EEH recovery
on all non-virtualized hosts is causing a kernel panic when
CONFIG_PCI_IOV is set. The panic is usually is of the form:
EEH: Notify device driver to resume
Unable to handle kernel paging request for instruction fetch
Faulting instruction address: 0x00000000
Oops: Kernel access of bad area, sig: 11 [#1]
<snip>
LR eeh_report_resume+0x218/0x220
Call Trace:
eeh_report_resume+0x1f0/0x220 (unreliable)
eeh_pe_dev_traverse+0x98/0x170
eeh_handle_normal_event+0x3f4/0x650
eeh_handle_event+0x188/0x380
eeh_event_handler+0x208/0x210
kthread+0x168/0x1b0
ret_from_kernel_thread+0x5c/0xb4
Cc: Bryant G. Ly <bryantly@linux.vnet.ibm.com>
Fixes: 856e1eb9bdd4("PCI/AER: Add uevents in AER and EEH error/resume")
Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
---
arch/powerpc/kernel/eeh_driver.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/eeh_driver.c b/arch/powerpc/kernel/eeh_driver.c
index beea2182d754..932858a293ea 100644
--- a/arch/powerpc/kernel/eeh_driver.c
+++ b/arch/powerpc/kernel/eeh_driver.c
@@ -384,7 +384,8 @@ static void *eeh_report_resume(void *data, void *userdata)
eeh_pcid_put(dev);
pci_uevent_ers(dev, PCI_ERS_RESULT_RECOVERED);
#ifdef CONFIG_PCI_IOV
- eeh_ops->notify_resume(eeh_dev_to_pdn(edev));
+ if (eeh_ops->notify_resume)
+ eeh_ops->notify_resume(eeh_dev_to_pdn(edev));
#endif
return NULL;
}
--
2.14.3
^ permalink raw reply related
* Re: [PATCH 16/18] crypto: talitos - do hw_context DMA mapping outside the requests
From: Herbert Xu @ 2018-02-22 11:47 UTC (permalink / raw)
To: Horia Geantă
Cc: Christophe LEROY, David S. Miller, linux-crypto@vger.kernel.org,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <VI1PR0402MB3342B99A1BEA5622F29F79EF98CF0@VI1PR0402MB3342.eurprd04.prod.outlook.com>
On Tue, Feb 20, 2018 at 11:32:25AM +0000, Horia Geantă wrote:
>
> If final/finup is optional, how is the final hash supposed to be retrieved?
Sometimes the computation ends with a partial hash, that's what
export is for. Also it is completely legal to abandon the hash
state entirely.
> According to documentation, these are the accepted flows (with the option to
> export/import a partial hash b/w update and final/finup):
>
> .init() -> .update() -> .final()
> ^ | |
> '----' '---> HASH
>
> .init() -> .update() -> .finup()
> ^ | |
> '----' '---> HASH
>
> .digest()
> |
> '---------------> HASH
The documentation is simply incomplete in this regard.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 4.14, 4.9] crypto: talitos - fix Kernel Oops on hashing an empty file
From: Christophe LEROY @ 2018-02-22 10:17 UTC (permalink / raw)
To: Horia Geantă, Greg Kroah-Hartman
Cc: Herbert Xu, linuxppc-dev@lists.ozlabs.org,
linux-crypto@vger.kernel.org, stable@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <AM0PR0402MB3329F7DB21610C75674BA7AD98CD0@AM0PR0402MB3329.eurprd04.prod.outlook.com>
Le 22/02/2018 à 09:30, Horia Geantă a écrit :
> On 2/22/2018 9:08 AM, Christophe Leroy wrote:
>> Upstream 87a81dce53b1ea61acaeefa5191a0376a2d1d721
>>
>> Performing the hash of an empty file leads to a kernel Oops
>>
>> [ 44.504600] Unable to handle kernel paging request for data at address 0x0000000c
>> [ 44.512819] Faulting instruction address: 0xc02d2be8
>> [ 44.524088] Oops: Kernel access of bad area, sig: 11 [#1]
>> [ 44.529171] BE PREEMPT CMPC885
>> [ 44.532232] CPU: 0 PID: 491 Comm: md5sum Not tainted 4.15.0-rc8-00211-g3a968610b6ea #81
>> [ 44.540814] NIP: c02d2be8 LR: c02d2984 CTR: 00000000
>> [ 44.545812] REGS: c6813c90 TRAP: 0300 Not tainted (4.15.0-rc8-00211-g3a968610b6ea)
>> [ 44.554223] MSR: 00009032 <EE,ME,IR,DR,RI> CR: 48222822 XER: 20000000
>> [ 44.560855] DAR: 0000000c DSISR: c0000000
>> [ 44.560855] GPR00: c02d28fc c6813d40 c6828000 c646fa40 00000001 00000001 00000001 00000000
>> [ 44.560855] GPR08: 0000004c 00000000 c000bfcc 00000000 28222822 100280d4 00000000 10020008
>> [ 44.560855] GPR16: 00000000 00000020 00000000 00000000 10024008 00000000 c646f9f0 c6179a10
>> [ 44.560855] GPR24: 00000000 00000001 c62f0018 c6179a10 00000000 c6367a30 c62f0000 c646f9c0
>> [ 44.598542] NIP [c02d2be8] ahash_process_req+0x448/0x700
>> [ 44.603751] LR [c02d2984] ahash_process_req+0x1e4/0x700
>> [ 44.608868] Call Trace:
>> [ 44.611329] [c6813d40] [c02d28fc] ahash_process_req+0x15c/0x700 (unreliable)
>> [ 44.618302] [c6813d90] [c02060c4] hash_recvmsg+0x11c/0x210
>> [ 44.623716] [c6813db0] [c0331354] ___sys_recvmsg+0x98/0x138
>> [ 44.629226] [c6813eb0] [c03332c0] __sys_recvmsg+0x40/0x84
>> [ 44.634562] [c6813f10] [c03336c0] SyS_socketcall+0xb8/0x1d4
>> [ 44.640073] [c6813f40] [c000d1ac] ret_from_syscall+0x0/0x38
>> [ 44.645530] Instruction dump:
>> [ 44.648465] 38c00001 7f63db78 4e800421 7c791b78 54690ffe 0f090000 80ff0190 2f870000
>> [ 44.656122] 40befe50 2f990001 409e0210 813f01bc <8129000c> b39e003a 7d29c214 913e003c
>>
>> This patch fixes that Oops by checking if src is NULL.
>>
>> Fixes: 6a1e8d14156d4 ("crypto: talitos - making mapping helpers more generic")
>> Cc: <stable@vger.kernel.org>
>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>
> Isn't this needed also in 4.15.y?
It is already in 4.15, see
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/drivers/crypto/talitos.c?h=v4.15.4&id=e76a4b126d1e7fbd0124cb885331a45e9a24f32b
Christophe
>
> Thanks,
> Horia
>
^ permalink raw reply
* Re: [PATCH 4.14, 4.9] crypto: talitos - fix Kernel Oops on hashing an empty file
From: Horia Geantă @ 2018-02-22 8:30 UTC (permalink / raw)
To: Christophe Leroy, Greg Kroah-Hartman
Cc: Herbert Xu, linuxppc-dev@lists.ozlabs.org,
linux-crypto@vger.kernel.org, stable@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20180222070616.A15E36CBD4@po15720vm.idsi0.si.c-s.fr>
On 2/22/2018 9:08 AM, Christophe Leroy wrote:=0A=
> Upstream 87a81dce53b1ea61acaeefa5191a0376a2d1d721=0A=
> =0A=
> Performing the hash of an empty file leads to a kernel Oops=0A=
> =0A=
> [ 44.504600] Unable to handle kernel paging request for data at address=
0x0000000c=0A=
> [ 44.512819] Faulting instruction address: 0xc02d2be8=0A=
> [ 44.524088] Oops: Kernel access of bad area, sig: 11 [#1]=0A=
> [ 44.529171] BE PREEMPT CMPC885=0A=
> [ 44.532232] CPU: 0 PID: 491 Comm: md5sum Not tainted 4.15.0-rc8-00211-=
g3a968610b6ea #81=0A=
> [ 44.540814] NIP: c02d2be8 LR: c02d2984 CTR: 00000000=0A=
> [ 44.545812] REGS: c6813c90 TRAP: 0300 Not tainted (4.15.0-rc8-00211=
-g3a968610b6ea)=0A=
> [ 44.554223] MSR: 00009032 <EE,ME,IR,DR,RI> CR: 48222822 XER: 200000=
00=0A=
> [ 44.560855] DAR: 0000000c DSISR: c0000000=0A=
> [ 44.560855] GPR00: c02d28fc c6813d40 c6828000 c646fa40 00000001 000000=
01 00000001 00000000=0A=
> [ 44.560855] GPR08: 0000004c 00000000 c000bfcc 00000000 28222822 100280=
d4 00000000 10020008=0A=
> [ 44.560855] GPR16: 00000000 00000020 00000000 00000000 10024008 000000=
00 c646f9f0 c6179a10=0A=
> [ 44.560855] GPR24: 00000000 00000001 c62f0018 c6179a10 00000000 c6367a=
30 c62f0000 c646f9c0=0A=
> [ 44.598542] NIP [c02d2be8] ahash_process_req+0x448/0x700=0A=
> [ 44.603751] LR [c02d2984] ahash_process_req+0x1e4/0x700=0A=
> [ 44.608868] Call Trace:=0A=
> [ 44.611329] [c6813d40] [c02d28fc] ahash_process_req+0x15c/0x700 (unrel=
iable)=0A=
> [ 44.618302] [c6813d90] [c02060c4] hash_recvmsg+0x11c/0x210=0A=
> [ 44.623716] [c6813db0] [c0331354] ___sys_recvmsg+0x98/0x138=0A=
> [ 44.629226] [c6813eb0] [c03332c0] __sys_recvmsg+0x40/0x84=0A=
> [ 44.634562] [c6813f10] [c03336c0] SyS_socketcall+0xb8/0x1d4=0A=
> [ 44.640073] [c6813f40] [c000d1ac] ret_from_syscall+0x0/0x38=0A=
> [ 44.645530] Instruction dump:=0A=
> [ 44.648465] 38c00001 7f63db78 4e800421 7c791b78 54690ffe 0f090000 80ff=
0190 2f870000=0A=
> [ 44.656122] 40befe50 2f990001 409e0210 813f01bc <8129000c> b39e003a 7d=
29c214 913e003c=0A=
> =0A=
> This patch fixes that Oops by checking if src is NULL.=0A=
> =0A=
> Fixes: 6a1e8d14156d4 ("crypto: talitos - making mapping helpers more gene=
ric")=0A=
> Cc: <stable@vger.kernel.org>=0A=
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>=0A=
=0A=
Isn't this needed also in 4.15.y?=0A=
=0A=
Thanks,=0A=
Horia=0A=
^ permalink raw reply
* [PATCH 4.14, 4.9] crypto: talitos - fix Kernel Oops on hashing an empty file
From: Christophe Leroy @ 2018-02-22 7:06 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-crypto, linux-kernel, linuxppc-dev, Herbert Xu, stable
Upstream 87a81dce53b1ea61acaeefa5191a0376a2d1d721
Performing the hash of an empty file leads to a kernel Oops
[ 44.504600] Unable to handle kernel paging request for data at address 0x0000000c
[ 44.512819] Faulting instruction address: 0xc02d2be8
[ 44.524088] Oops: Kernel access of bad area, sig: 11 [#1]
[ 44.529171] BE PREEMPT CMPC885
[ 44.532232] CPU: 0 PID: 491 Comm: md5sum Not tainted 4.15.0-rc8-00211-g3a968610b6ea #81
[ 44.540814] NIP: c02d2be8 LR: c02d2984 CTR: 00000000
[ 44.545812] REGS: c6813c90 TRAP: 0300 Not tainted (4.15.0-rc8-00211-g3a968610b6ea)
[ 44.554223] MSR: 00009032 <EE,ME,IR,DR,RI> CR: 48222822 XER: 20000000
[ 44.560855] DAR: 0000000c DSISR: c0000000
[ 44.560855] GPR00: c02d28fc c6813d40 c6828000 c646fa40 00000001 00000001 00000001 00000000
[ 44.560855] GPR08: 0000004c 00000000 c000bfcc 00000000 28222822 100280d4 00000000 10020008
[ 44.560855] GPR16: 00000000 00000020 00000000 00000000 10024008 00000000 c646f9f0 c6179a10
[ 44.560855] GPR24: 00000000 00000001 c62f0018 c6179a10 00000000 c6367a30 c62f0000 c646f9c0
[ 44.598542] NIP [c02d2be8] ahash_process_req+0x448/0x700
[ 44.603751] LR [c02d2984] ahash_process_req+0x1e4/0x700
[ 44.608868] Call Trace:
[ 44.611329] [c6813d40] [c02d28fc] ahash_process_req+0x15c/0x700 (unreliable)
[ 44.618302] [c6813d90] [c02060c4] hash_recvmsg+0x11c/0x210
[ 44.623716] [c6813db0] [c0331354] ___sys_recvmsg+0x98/0x138
[ 44.629226] [c6813eb0] [c03332c0] __sys_recvmsg+0x40/0x84
[ 44.634562] [c6813f10] [c03336c0] SyS_socketcall+0xb8/0x1d4
[ 44.640073] [c6813f40] [c000d1ac] ret_from_syscall+0x0/0x38
[ 44.645530] Instruction dump:
[ 44.648465] 38c00001 7f63db78 4e800421 7c791b78 54690ffe 0f090000 80ff0190 2f870000
[ 44.656122] 40befe50 2f990001 409e0210 813f01bc <8129000c> b39e003a 7d29c214 913e003c
This patch fixes that Oops by checking if src is NULL.
Fixes: 6a1e8d14156d4 ("crypto: talitos - making mapping helpers more generic")
Cc: <stable@vger.kernel.org>
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
drivers/crypto/talitos.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index dff88838dce7..42913116620a 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -1124,6 +1124,11 @@ int talitos_sg_map(struct device *dev, struct scatterlist *src,
struct talitos_private *priv = dev_get_drvdata(dev);
bool is_sec1 = has_ftr_sec1(priv);
+ if (!src) {
+ *ptr = zero_entry;
+ return 1;
+ }
+
to_talitos_ptr_len(ptr, len, is_sec1);
to_talitos_ptr_ext_set(ptr, 0, is_sec1);
--
2.13.3
^ permalink raw reply related
* Re: [PATCH v12 01/22] selftests/x86: Move protecton key selftest to arch neutral directory
From: Ingo Molnar @ 2018-02-22 5:51 UTC (permalink / raw)
To: Ram Pai
Cc: shuahkh, linux-kselftest, mpe, linuxppc-dev, linux-mm, x86,
linux-arch, linux-doc, linux-kernel, mingo, akpm, dave.hansen,
benh, paulus, khandual, aneesh.kumar, bsingharora, hbabu, mhocko,
bauerman, ebiederm, arnd
In-Reply-To: <1519264541-7621-2-git-send-email-linuxram@us.ibm.com>
* Ram Pai <linuxram@us.ibm.com> wrote:
> cc: Dave Hansen <dave.hansen@intel.com>
> cc: Florian Weimer <fweimer@redhat.com>
> Signed-off-by: Ram Pai <linuxram@us.ibm.com>
> ---
> tools/testing/selftests/vm/Makefile | 1 +
> tools/testing/selftests/vm/pkey-helpers.h | 223 ++++
> tools/testing/selftests/vm/protection_keys.c | 1407 +++++++++++++++++++++++++
> tools/testing/selftests/x86/Makefile | 2 +-
> tools/testing/selftests/x86/pkey-helpers.h | 223 ----
> tools/testing/selftests/x86/protection_keys.c | 1407 -------------------------
> 6 files changed, 1632 insertions(+), 1631 deletions(-)
> create mode 100644 tools/testing/selftests/vm/pkey-helpers.h
> create mode 100644 tools/testing/selftests/vm/protection_keys.c
> delete mode 100644 tools/testing/selftests/x86/pkey-helpers.h
> delete mode 100644 tools/testing/selftests/x86/protection_keys.c
Acked-by: Ingo Molnar <mingo@kernel.org>
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH] ocxl: Add get_metadata IOCTL to share OCXL information to userspace
From: Balbir Singh @ 2018-02-22 5:32 UTC (permalink / raw)
To: Alastair D'Silva
Cc: Frederic Barrat, Arnd Bergmann, frederic.barrat, Greg KH,
linux-kernel@vger.kernel.org, linuxppc-dev, Andrew Donnellan
In-Reply-To: <1519271512.2867.14.camel@au1.ibm.com>
On Thu, Feb 22, 2018 at 2:51 PM, Alastair D'Silva <alastair@au1.ibm.com> wrote:
> On Thu, 2018-02-22 at 14:46 +1100, Balbir Singh wrote:
> <snip>
>> lpc_size could be added. It's currently useless to the library, but
>> > doesn't
>> > hurt. The one which was giving me troubles on a previous version of
>> > this
>> > patch was the lpc numa node ID, since that was experimental code
>> > and felt
>> > out of place considering what's been upstreamed in skiboot and
>> > linux so far.
>> >
>>
>> Yeah, I think metadata will evolve for a while till it settle's down.
>> Since ocxl_ioctl_get_metadata is exposed via uapi, a newer program
>> calling an older kernel will never work, since the size of that
>> struct
>> will always be larger than what the OS supports and our
>> copy_to_user()
>> will fail. The other option is for the user program to try all
>> possible versions till one succeeds, that is bad as well. I think
>> there are a few ways around it, if we care about this combination.
>>
>> Balbir Singh.
>>
>
> We have a number of reserved members at the end of the struct which can
> be re-purposed for future information (with a corresponding bump of the
> version number).
Good point, agreed
Balbir Singh.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox