linux.git/arch/s390/kernel, branch v4.12

arch: remove unused macro/function thread_saved_pc()

2017-06-28T23:13:57+00:00

The only user of thread_saved_pc() in non-arch-specific code was removed
in commit 8243d5597793 ("sched/core: Remove pointless printout in
sched_show_task()").  Remove the implementations as well.

Some architectures use thread_saved_pc() in their arch-specific code.
Leave their thread_saved_pc() intact.

Signed-off-by: Tobias Klauser 
Acked-by: Geert Uytterhoeven 
Cc: Ingo Molnar 
Signed-off-by: Linus Torvalds

s390/ipl: revert Load Normal semantics for LPAR CCW-type re-IPL

2017-06-14T13:35:31+00:00

This reverts the two commits

7afbeb6df2aa ("s390/ipl: always use load normal for CCW-type re-IPL")
0f7451ff3ab8 ("s390/ipl: use load normal for LPAR re-ipl")

The two commits did not take into account that behavior of standby
memory changes fundamentally if the re-IPL method is changed from
Load Clear to Load Normal.

In case of the old re-IPL clear method all memory that was initially
in standby state will be put into standby state again within the
re-IPL process. Or in other words: memory that was brought online
before a re-IPL will be offline again after a reboot.

Given that we use different re-IPL methods depending on the hypervisor
and CCW-type vs SCSI re-IPL it is not easy to tell in advance when and
why memory will stay online or will be offline after a re-IPL.
This does also have other side effects, since memory that is online
from the beginning will be in ZONE_NORMAL by default vs ZONE_MOVABLE
for memory that is offline.

Therefore, before the change, a user could online and offline memory
easily since standby memory was always in ZONE_NORMAL.  After the
change, and a re-IPL, this depended on which memory parts were online
before the re-IPL.

From a usability point of view the current behavior is more than
suboptimal. Therefore revert these changes until we have a better
solution and get back to a consistent behavior. The bad thing about
this is that the time required for a re-IPL will be significantly
increased for configurations with several 100GB or 1TB of memory.

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

s390/kvm: do not rely on the ILC on kvm host protection fauls

2017-05-17T10:34:03+00:00

For most cases a protection exception in the host (e.g. copy
on write or dirty tracking) on the sie instruction will indicate
an instruction length of 4. Turns out that there are some corner
cases (e.g. runtime instrumentation) where this is not necessarily
true and the ILC is unpredictable.

Let's replace our 4 byte rewind_pad with 3 byte nops to prepare for
all possible ILCs.

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

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux

2017-05-16T16:24:44+00:00

Pull s390 fixes from Martin Schwidefsky:

 - convert the debug feature to refcount_t

 - reduce the copy size for strncpy_from_user

 - 8 bug fixes

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390/virtio: change virtio_feature_desc:features type to __le32
  s390: convert debug_info.ref_count from atomic_t to refcount_t
  s390: move _text symbol to address higher than zero
  s390/qdio: increase string buffer size
  s390/ccwgroup: increase string buffer size
  s390/topology: let topology_mnest_limit() return unsigned char
  s390/uaccess: use sane length for __strncpy_from_user()
  s390/uprobes: fix compile for !KPROBES
  s390/ftrace: fix compile for !MODULES
  s390/cputime: fix incorrect system time

s390: convert debug_info.ref_count from atomic_t to refcount_t

2017-05-11T14:35:32+00:00

refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.

Signed-off-by: Elena Reshetova 
Signed-off-by: Hans Liljestrand 
Signed-off-by: Kees Cook 
Signed-off-by: David Windsor 
Signed-off-by: Heiko Carstens 
Signed-off-by: Martin Schwidefsky

s390: move _text symbol to address higher than zero

2017-05-09T08:44:38+00:00

The perf tool assumes that kernel symbols are never present at address
zero. In fact it assumes if functions that map symbols to addresses
return zero, that the symbol was not found.

Given that s390's _text symbol historically is located at address zero
this yields at least a couple of false errors and warnings in one of
perf's test cases about not present symbols ("perf test 1").

To fix this simply move the _text symbol to address 0x200, just behind
the initial psw and channel program located at the beginning of the
kernel image. This is now hard coded within the linker script.

I tried a nicer solution which moves the initial psw and channel
program into an own section. However that would move the symbols
within the "real" head.text section to different addresses, since the
".org" statements within head.S are relative to the head.text
section. If there is a new section in front, everything else will be
moved. Alternatively I could have adjusted all ".org" statements. But
this current solution seems to be the easiest one, since nobody really
cares where the _text symbol is actually located.

Reported-by: Zvonko Kosic 
Signed-off-by: Heiko Carstens 
Signed-off-by: Martin Schwidefsky

s390: use set_memory.h header

2017-05-09T00:15:13+00:00

set_memory_* functions have moved to set_memory.h.  Switch to this
explicitly

Link: http://lkml.kernel.org/r/1488920133-27229-5-git-send-email-labbott@redhat.com
Signed-off-by: Laura Abbott 
Acked-by: Heiko Carstens 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

cpumask: make "nr_cpumask_bits" unsigned

2017-05-09T00:15:11+00:00

Bit searching functions accept "unsigned long" indices but
"nr_cpumask_bits" is "int" which is signed, so inevitable sign
extensions occur on x86_64.  Those MOVSX are #1 MOVSX bloat by number of
uses across whole kernel.

Change "nr_cpumask_bits" to unsigned, this number can't be negative
after all.  It allows to do implicit zero-extension on x86_64 without
MOVSX.

Change signed comparisons into unsigned comparisons where necessary.

Other uses looks fine because it is either argument passed to a function
or comparison is already unsigned.

Net win on allyesconfig type of kernel: ~2.8 KB (!)

	add/remove: 0/0 grow/shrink: 8/725 up/down: 93/-2926 (-2833)
	function                                     old     new   delta
	xen_exit_mmap                                691     735     +44
	qstat_read                                   426     440     +14
	__cpufreq_cooling_register                  1678    1687      +9
	trace_rb_cpu_prepare                         447     455      +8
	vermagic                                      54      60      +6
	nfp_driver_version                            54      60      +6
	rcu_torture_stats_print                     1147    1151      +4
	find_next_push_cpu                           267     269      +2
	xen_irq_resume                               961     960      -1
				...
	init_vp_index                                946     906     -40
	od_set_powersave_bias                        328     281     -47
	power_cpu_exit                               193     139     -54
	arch_show_interrupts                        3538    3484     -54
	select_idle_sibling                         1558    1471     -87
	Total: Before=158358910, After=158356077, chg -0.00%

Same arguments apply to "nr_cpu_ids" but I haven't yet found enough
courage to delve into this issue (and proper fix may require new type
"cpu_t" which is whole separate story).

Link: http://lkml.kernel.org/r/20170309205322.GA1728@avx2
Signed-off-by: Alexey Dobriyan 
Cc: Rusty Russell 
Cc: Heiko Carstens 
Cc: Martin Schwidefsky 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

s390/ftrace: fix compile for !MODULES

2017-05-03T07:08:57+00:00

Fix this compile error if CONFIG_MODULES is disabled:

arch/s390/built-in.o: In function `ftrace_plt_init':
arch/s390/kernel/ftrace.o:(.init.text+0x34cc): undefined reference to `module_alloc'

Reported-by: Rob Landley 
Signed-off-by: Heiko Carstens 
Signed-off-by: Martin Schwidefsky

s390/cputime: fix incorrect system time

2017-05-03T07:08:57+00:00

git commit c5328901aa1db134 "[S390] entry[64].S improvements" removed
the update of the exit_timer lowcore field from the critical section
cleanup of the .Lsysc_restore/.Lsysc_done and .Lio_restore/.Lio_done
blocks. If the PSW is updated by the critical section cleanup to point to
user space again, the interrupt entry code will do a vtime calculation
after the cleanup completed with an exit_timer value which has *not* been
updated. Due to this incorrect system time deltas are calculated.

If an interrupt occured with an old PSW between .Lsysc_restore/.Lsysc_done
or .Lio_restore/.Lio_done update __LC_EXIT_TIMER with the system entry
time of the interrupt.

Cc: stable@vger.kernel.org # 3.3+
Tested-by: Christian Borntraeger 
Signed-off-by: Martin Schwidefsky