From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755771AbbGTHeX (ORCPT ); Mon, 20 Jul 2015 03:34:23 -0400 Received: from mail-wg0-f44.google.com ([74.125.82.44]:35592 "EHLO mail-wg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755480AbbGTHeW (ORCPT ); Mon, 20 Jul 2015 03:34:22 -0400 Date: Mon, 20 Jul 2015 09:34:17 +0200 From: Ingo Molnar To: Guenter Cc: Dave Hansen , linux-kernel@vger.kernel.org, Martin Schwidefsky , linux-s390@vger.kernel.org, linux390@de.ibm.com, Peter Zijlstra , Dave Hansen Subject: sched, s390: Fix the fallout of increasing the offset of 'thread_struct' within 'task_struct' Message-ID: <20150720073417.GA10134@gmail.com> References: <20150718232717.GA3235@groeck-UX31A> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150718232717.GA3235@groeck-UX31A> 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 * 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;