linux-toradex.git/arch/s390, branch v3.7.8

s390/thp: implement pmdp_set_wrprotect()

2013-02-04T00:27:01+00:00

commit be3286507dab888d4aad9f91fd6ff5202b24cd5b upstream.

On s390, an architecture-specific implementation of the function
pmdp_set_wrprotect() is missing and the generic version is currently
being used. The generic version does not flush the tlb as it would be
needed on s390 when modifying an active pmd, which can lead to subtle
tlb errors on s390 when using transparent hugepages.

This patch adds an s390-specific implementation of pmdp_set_wrprotect()
including the missing tlb flush.

Signed-off-by: Gerald Schaefer 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Greg Kroah-Hartman

s390/time: fix sched_clock() overflow

2013-01-21T19:44:34+00:00

commit ed4f20943cd4c7b55105c04daedf8d63ab6d499c upstream.

Converting a 64 Bit TOD format value to nanoseconds means that the value
must be divided by 4.096. In order to achieve that we multiply with 125
and divide by 512.
When used within sched_clock() this triggers an overflow after appr.
417 days. Resulting in a sched_clock() return value that is much smaller
than previously and therefore may cause all sort of weird things in
subsystems that rely on a monotonic sched_clock() behaviour.

To fix this implement a tod_to_ns() helper function which converts TOD
values without overflow and call this function from both places that
open coded the conversion: sched_clock() and kvm_s390_handle_wait().

Reviewed-by: Martin Schwidefsky 
Signed-off-by: Heiko Carstens 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Greg Kroah-Hartman

s390/kvm: Fix address space mixup

2013-01-17T16:45:44+00:00

commit ce6a04ac1b759beafc88dbc443ae5da867579eeb upstream.

I was chasing down a bug of random validity intercepts on s390.
(guest prefix page not mapped in the host virtual aspace). Turns out
that the problem was a wrong address space control element. The
cause was quite complex:

During paging activity a DAT protection during SIE caused a program
interrupt. Normally, the sie retry loop tries to catch all
interrupts during and shortly before sie to rerun the setup. The
problem is now that protection causes a suppressing program interrupt,
causing the PSW to point to the instruction AFTER SIE in case of DAT
protection. This confused the logic of the retry loop to not trigger,
instead we jumped directly back to SIE after return from
the program  interrupt. (the protection fault handler itself did
a rewind of the psw). This usually works quite well, but:

If now the protection fault handler has to wait, another program
might be scheduled in. Later on the sie process will be schedules
in again. In that case the content of CR1 (primary address space)
will be wrong because switch_to will put the user space ASCE into CR1
and not the guest ASCE.

In addition the program parameter is also wrong for every protection
fault of a guest, since we dont issue the SPP instruction.

So lets also check for PSW == instruction after SIE in the program
check handler. Instead of expensively checking all program
interruption codes that might be suppressing we assume that a program
interrupt pointing after SIE was always a program interrupt in SIE.
(Otherwise we have a kernel bug anyway).

We also have to compensate the rewinding, since the C-level handlers
will do that. Therefore we need to add a nop with the same length
as SIE before the sie_loop.

Signed-off-by: Christian Borntraeger 
Signed-off-by: Martin Schwidefsky 
CC: Heiko Carstens 
Signed-off-by: Greg Kroah-Hartman

s390/kvm: dont announce RRBM support

2013-01-17T16:45:44+00:00

commit 87cac8f879a5ecd7109dbe688087e8810b3364eb upstream.

Newer kernels (linux-next with the transparent huge page patches)
use rrbm if the feature is announced via feature bit 66.
RRBM will cause intercepts, so KVM does not handle it right now,
causing an illegal instruction in the guest.
The  easy solution is to disable the feature bit for the guest.

This fixes bugs like:
Kernel BUG at 0000000000124c2a [verbose debug info unavailable]
illegal operation: 0001 [#1] SMP
Modules linked in: virtio_balloon virtio_net ipv6 autofs4
CPU: 0 Not tainted 3.5.4 #1
Process fmempig (pid: 659, task: 000000007b712fd0, ksp: 000000007bed3670)
Krnl PSW : 0704d00180000000 0000000000124c2a (pmdp_clear_flush_young+0x5e/0x80)
     R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3
     00000000003cc000 0000000000000004 0000000000000000 0000000079800000
     0000000000040000 0000000000000000 000000007bed3918 000000007cf40000
     0000000000000001 000003fff7f00000 000003d281a94000 000000007bed383c
     000000007bed3918 00000000005ecbf8 00000000002314a6 000000007bed36e0
 Krnl Code:>0000000000124c2a: b9810025          ogr     %r2,%r5
           0000000000124c2e: 41343000           la      %r3,0(%r4,%r3)
           0000000000124c32: a716fffa           brct    %r1,124c26
           0000000000124c36: b9010022           lngr    %r2,%r2
           0000000000124c3a: e3d0f0800004       lg      %r13,128(%r15)
           0000000000124c40: eb22003f000c       srlg    %r2,%r2,63
[ 2150.713198] Call Trace:
[ 2150.713223] ([<00000000002312c4>] page_referenced_one+0x6c/0x27c)
[ 2150.713749]  [<0000000000233812>] page_referenced+0x32a/0x410
[...]

Signed-off-by: Martin Schwidefsky 
CC: Alex Graf 
Signed-off-by: Christian Borntraeger 
Signed-off-by: Marcelo Tosatti 
Signed-off-by: Greg Kroah-Hartman

open*(2) compat fixes (s390, arm64)

2012-12-02T18:46:38+00:00

The usual rules for open()/openat()/open_by_handle_at() are
 1) native 32bit - don't force O_LARGEFILE in flags
 2) native 64bit - force O_LARGEFILE in flags
 3) compat on 64bit host - as for native 32bit
 4) native 32bit ABI for 64bit system (mips/n32, x86/x32) - as for
    native 64bit

There are only two exceptions - s390 compat has open() forcing
O_LARGEFILE and arm64 compat has open_by_handle_at() doing the same
thing.  The same binaries on native host (s390/31 and arm resp.) will
*not* force O_LARGEFILE, so IMO both are emulation bugs.

Objections? The fix is obvious...

Signed-off-by: Al Viro 
Signed-off-by: Linus Torvalds

s390/mm: have 16 byte aligned struct pages

2012-11-13T10:03:09+00:00

Select HAVE_ALIGNED_STRUCT_PAGE on s390, so that the slub allocator can make
use of compare and swap double for lockless updates. This increases the size
of struct page to 64 bytes (instead of 56 bytes), however the performance gain
justifies the increased size:

- now excactly four struct pages fit into a single cache line; the
  case that accessing a struct page causes two cache line loads
  does not exist anymore.
- calculating the offset of a struct page within the memmap array
  is only a simple shift instead of a more expensive multiplication.

A "hackbench 200 process 200" run on a 32 cpu system did show an 8% runtime
improvement.

Signed-off-by: Heiko Carstens 
Signed-off-by: Martin Schwidefsky

s390/gup: fix access_ok() usage in __get_user_pages_fast()

2012-11-13T10:02:28+00:00

access_ok() returns always "true" on s390. Therefore all access_ok()
invocations are rather pointless.
However when walking page tables we need to make sure that everything
is within bounds of the ASCE limit of the task's address space.
So remove the access_ok() call and add the same check we have in
get_user_pages_fast().

Reviewed-by: Gerald Schaefer 
Signed-off-by: Heiko Carstens 
Signed-off-by: Martin Schwidefsky

s390/gup: add missing TASK_SIZE check to get_user_pages_fast()

2012-11-13T10:02:26+00:00

When walking page tables we need to make sure that everything
is within bounds of the ASCE limit of the task's address space.
Otherwise we might calculate e.g. a pud pointer which is not
within a pud and dereference it.
So check against TASK_SIZE (which is the ASCE limit) before
walking page tables.

Reviewed-by: Gerald Schaefer 
Cc: stable@vger.kernel.org
Signed-off-by: Heiko Carstens 
Signed-off-by: Martin Schwidefsky

s390/topology: fix core id vs physical package id mix-up

2012-11-12T15:24:38+00:00

The current topology code confuses core id vs physical package id.

In other words /sys/devices/system/cpu/cpuX/topology/core_id
displays the physical_package_id (aka socket id) instead of the
core id.
The physical_package_id sysfs attribute always displays "-1"
instead of the socket id.

Fix this mix-up with a small patch which defines and initializes
topology_physical_package_id correctly and fixes the broken
core id handling.

Signed-off-by: Heiko Carstens 
Signed-off-by: Martin Schwidefsky

s390/signal: set correct address space control

2012-11-12T15:24:38+00:00

If user space is running in primary mode it can switch to secondary
or access register mode, this is used e.g. in the clock_gettime code
of the vdso. If a signal is delivered to the user space process while
it has been running in access register mode the signal handler is
executed in access register mode as well which will result in a crash
most of the time.

Set the address space control bits in the PSW to the default for the
execution of the signal handler and make sure that the previous
address space control is restored on signal return. Take care
that user space can not switch to the kernel address space by
modifying the registers in the signal frame.

Cc: stable@vger.kernel.org
Signed-off-by: Martin Schwidefsky