Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755676AbbGTIAi (ORCPT ); Mon, 20 Jul 2015 04:00:38 -0400 Received: from mail-wi0-f174.google.com ([209.85.212.174]:36303 "EHLO mail-wi0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755178AbbGTIAh (ORCPT ); Mon, 20 Jul 2015 04:00:37 -0400 Date: Mon, 20 Jul 2015 10:00:32 +0200 From: Ingo Molnar To: Heiko Carstens Cc: Linus Torvalds , linux-kernel@vger.kernel.org, Thomas Gleixner , "H. Peter Anvin" , Andy Lutomirski , Dave Hansen , Andrew Morton , Oleg Nesterov , Martin Schwidefsky Subject: [PATCH] sched, s390: Fix the fallout of increasing the offset of 'thread_struct' within 'task_struct' Message-ID: <20150720080032.GA12468@gmail.com> References: <20150718031810.GA19818@gmail.com> <20150720072037.GA3607@osiris> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150720072037.GA3607@osiris> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4653 Lines: 115 * Heiko Carstens wrote: > > I've tested it on a number of x86 platforms, and I cross-built it to a handful > > of architectures: > > > > (warns) (warns) > > testing x86-64: -git: pass ( 0), -tip: pass ( 0) > > testing x86-32: -git: pass ( 0), -tip: pass ( 0) > > testing arm: -git: pass ( 1359), -tip: pass ( 1359) > > testing cris: -git: pass ( 1031), -tip: pass ( 1031) > > testing m32r: -git: pass ( 1135), -tip: pass ( 1135) > > testing m68k: -git: pass ( 1471), -tip: pass ( 1471) > > testing mips: -git: pass ( 1162), -tip: pass ( 1162) > > testing mn10300: -git: pass ( 1058), -tip: pass ( 1058) > > testing parisc: -git: pass ( 1846), -tip: pass ( 1846) > > testing sparc: -git: pass ( 1185), -tip: pass ( 1185) > > > > ... so I hope the cross-arch impact 'none', as intended. > > > > (by Dave Hansen) > > Unfortunately not true. It breaks the build on s390 since a couple of > displacements used in asm code now get too large: > > arch/s390/kernel/entry.S:181: Error: operand out of range (0x00000000000018a8 is not between 0x0000000000000000 and 0x0000000000000fff) > arch/s390/kernel/entry.S:191: Error: operand out of range (0x00000000000018a8 is not between 0x0000000000000000 and 0x0000000000000fff) > arch/s390/kernel/entry.S:423: Error: operand out of range (0x0000000000001924 is not between 0x0000000000000000 and 0x0000000000000fff) > arch/s390/kernel/entry.S:437: Error: operand out of range (0x00000000000018e8 is not between 0x0000000000000000 and 0x0000000000000fff) > arch/s390/kernel/entry.S:438: Error: operand out of range (0x00000000000018e0 is not between 0x0000000000000000 and 0x0000000000000fff) > arch/s390/kernel/entry.S:439: Error: operand out of range (0x00000000000018f0 is not between 0x0000000000000000 and 0x0000000000000fff) > make[1]: *** [arch/s390/kernel/entry.o] Error 1 > > Let's see how we can fix this. There's also a traps.c build breakage reported below - and an RFC fix for it. Thanks, Ingo =========================> * Guenter wrote: > Hi, > > Commit 0c8c0f03e3a2 ("x86/fpu, sched: Dynamically allocate 'struct fpu'") > causes s390 builds in mainline to fail as follows. > > arch/s390/kernel/traps.c: Assembler messages: > arch/s390/kernel/traps.c:262: Error: operand out of range > (0x00000000000023e8 is not between 0x0000000000000000 and 0x0000000000000fff) > arch/s390/kernel/traps.c:300: Error: operand out of range > (0x00000000000023e8 is not between 0x0000000000000000 and 0x0000000000000fff) Yeah, so I'm really out on a limb here as I know next to nothing about s390 assembly, but the build failure appears to be analogous to the arm64 one: the offset of thread_struct fields within task_struct increased due to commit 0c8c0f03e3a2 ("x86/fpu, sched: Dynamically allocate 'struct fpu'"), which increased assembly offsets beyond the limit this instruction can apparently encode. Does the (untested!) patch below help? It's an equivalent transformation on the C side, but it might cause GCC to generate different assembly code, because we now have a temporary variable with much smaller offsets. The code is also a tiny bit cleaner this way, as the 'current->thread.fp_regs' pattern isn't repeated twice. In case this works: Signed-off-by: Ingo Molnar Thanks, Ingo ================> arch/s390/kernel/traps.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/s390/kernel/traps.c b/arch/s390/kernel/traps.c index 4d96c9f53455..db6f0eec55b5 100644 --- a/arch/s390/kernel/traps.c +++ b/arch/s390/kernel/traps.c @@ -251,6 +251,7 @@ int alloc_vector_registers(struct task_struct *tsk) void vector_exception(struct pt_regs *regs) { + s390_fp_regs *fp_regs = ¤t->thread.fp_regs; int si_code, vic; if (!MACHINE_HAS_VX) { @@ -259,8 +260,9 @@ void vector_exception(struct pt_regs *regs) } /* get vector interrupt code from fpc */ - asm volatile("stfpc %0" : "=m" (current->thread.fp_regs.fpc)); - vic = (current->thread.fp_regs.fpc & 0xf00) >> 8; + asm volatile("stfpc %0" : "=m" (fp_regs->fpc)); + vic = (fp_regs->fpc & 0xf00) >> 8; + switch (vic) { case 1: /* invalid vector operation */ si_code = FPE_FLTINV; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/