linux-kernel - Re: sched, s390: Fix the fallout of increasing the offset of 'thread_struct' within 'task

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 20 Jul 2015 07:31:55 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Ingo Molnar <mingo@...nel.org>
CC:	Dave Hansen <dave.hansen@...ux.intel.com>,
	linux-kernel@...r.kernel.org,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	linux-s390@...r.kernel.org, linux390@...ibm.com,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Dave Hansen <dave@...1.net>
Subject: Re: sched, s390: Fix the fallout of increasing the offset of 'thread_struct'
 within 'task_struct'

On 07/20/2015 12:34 AM, Ingo Molnar wrote:
>
> * Guenter <linux@...ck-us.net> 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 <mingo@...nel.org>
>
> 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 = &current->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;
> +

No idea why, but this still fails with the same error (I suspect the compiler
tries to optimize the fp_regs variable away). I can compile the code by using
a local variable '__u32 fpc', but obviously I don't know if that is correct.
I don't have a working qemu configuration for s390, so I can not run any tests.

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/