BMC/Intel-BMC/linux.git/arch/s390/kernel/process.c, branch dev-4.3

s390/kernel: remove save_fpu_regs() parameter and use __LC_CURRENT instead

2015-08-03T08:04:37+00:00

All calls to save_fpu_regs() specify the fpu structure of the current task pointer as parameter. The task pointer of the current task can also be retrieved from the CPU lowcore directly. Remove the parameter definition, load the __LC_CURRENT task pointer from the CPU lowcore, and rebase the FPU structure onto the task structure. Apply the same approach for the load_fpu_regs() function. Reviewed-by: Heiko Carstens Signed-off-by: Hendrik Brueckner Signed-off-by: Martin Schwidefsky

s390/kernel: lazy restore fpu registers

2015-07-22T07:58:01+00:00

Improve the save and restore behavior of FPU register contents to use the vector extension within the kernel. The kernel does not use floating-point or vector registers and, therefore, saving and restoring the FPU register contents are performed for handling signals or switching processes only. To prepare for using vector instructions and vector registers within the kernel, enhance the save behavior and implement a lazy restore at return to user space from a system call or interrupt. To implement the lazy restore, the save_fpu_regs() sets a CPU information flag, CIF_FPU, to indicate that the FPU registers must be restored. Saving and setting CIF_FPU is performed in an atomic fashion to be interrupt-safe. When the kernel wants to use the vector extension or wants to change the FPU register state for a task during signal handling, the save_fpu_regs() must be called first. The CIF_FPU flag is also set at process switch. At return to user space, the FPU state is restored. In particular, the FPU state includes the floating-point or vector register contents, as well as, vector-enablement and floating-point control. The FPU state restore and clearing CIF_FPU is also performed in an atomic fashion. For KVM, the restore of the FPU register state is performed when restoring the general-purpose guest registers before the SIE instructions is started. Because the path towards the SIE instruction is interruptible, the CIF_FPU flag must be checked again right before going into SIE. If set, the guest registers must be reloaded again by re-entering the outer SIE loop. This is the same behavior as if the SIE critical section is interrupted. Signed-off-by: Hendrik Brueckner Signed-off-by: Martin Schwidefsky

s390/kernel: dynamically allocate FP register save area

2015-07-22T07:58:00+00:00

Make the floating-point save area dynamically allocated and uses a flag to distinguish whether a task uses floating-point or vector registers. Signed-off-by: Hendrik Brueckner Signed-off-by: Martin Schwidefsky

s390/kernel: introduce fpu-internal.h with fpu helper functions

2015-07-22T07:58:00+00:00

Introduce a new structure to manage FP and VX registers. Refactor the save and restore of floating point and vector registers with a set of helper functions in fpu-internal.h. Signed-off-by: Hendrik Brueckner Signed-off-by: Martin Schwidefsky

s390/process: fix sfpc inline assembly

2015-07-13T09:02:18+00:00

The sfpc inline assembly within execve_tail() may incorrectly set bits 28-31 of the sfpc instruction to a value which is not zero. These bits however are currently unused and therefore should be zero so we won't get surprised if these bits will be used in the future. Therefore remove the second operand from the inline assembly. Cc: Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky

s390: remove 31 bit support

2015-03-25T10:49:33+00:00

Remove the 31 bit support in order to reduce maintenance cost and effectively remove dead code. Since a couple of years there is no distribution left that comes with a 31 bit kernel. The 31 bit kernel also has been broken since more than a year before anybody noticed. In addition I added a removal warning to the kernel shown at ipl for 5 minutes: a960062e5826 ("s390: add 31 bit warning message") which let everybody know about the plan to remove 31 bit code. We didn't get any response. Given that the last 31 bit only machine was introduced in 1999 let's remove the code. Anybody with 31 bit user space code can still use the compat mode. Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky

s390/process: free vx save area when releasing tasks

2015-02-10T15:39:05+00:00

If a task uses vector registers, a save area is allocated to save/restore register states. Free the save area when releasing the task. Found the Memory leak with kmemleak: unreferenced object 0x72885e00 (size 512): comm "vx-test", pid 26123, jiffies 4294945635 (age 256.810s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 01 db 71 06 41 .............q.A 00 00 00 00 00 00 00 00 24 f7 a9 a7 51 94 79 bb ........$...Q.y. backtrace: [<00000000002d1c8a>] kmem_cache_alloc_trace+0x272/0x3d0 [<00000000001014ac>] alloc_vector_registers+0x54/0x138 [<00000000001017c8>] data_exception+0x158/0x1b0 [<00000000008b551e>] pgm_check_handler+0x13e/0x180 [<00000000800008b6>] 0x800008b6 Signed-off-by: Hendrik Brueckner Signed-off-by: Martin Schwidefsky

s390: avoid z13 cache aliasing

2015-01-22T11:15:59+00:00

Avoid cache aliasing on z13 by aligning shared objects to multiples of 512K. The virtual addresses of a page from a shared file needs to have identical bits in the range 2^12 to 2^18. Signed-off-by: Martin Schwidefsky

s390/simd: clear vector register pointer on fork/clone

2014-12-08T08:42:35+00:00

The copy_thread function fails to reset the p->thread.vxrs pointer. This causes the child to use the same vector register save area, causing both data corruptions and multiple frees of the memory for the save area after the tasks sharing the save area terminate. Signed-off-by: Martin Schwidefsky

s390/kprobes: make use of NOKPROBE_SYMBOL()

2014-10-27T12:27:28+00:00

Use NOKPROBE_SYMBOL() instead of __kprobes annotation. Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky