<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/s390/kernel, branch linux-5.0.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.0.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.0.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2019-05-31T13:44:57Z</updated>
<entry>
<title>s390/kexec_file: Fix detection of text segment in ELF loader</title>
<updated>2019-05-31T13:44:57Z</updated>
<author>
<name>Philipp Rudo</name>
</author>
<published>2019-04-01T10:48:43Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ff4e79bbe519f5152200188b664f02ae7b040927'/>
<id>urn:sha1:ff4e79bbe519f5152200188b664f02ae7b040927</id>
<content type='text'>
[ Upstream commit 729829d775c9a5217abc784b2f16087d79c4eec8 ]

To register data for the next kernel (command line, oldmem_base, etc.) the
current kernel needs to find the ELF segment that contains head.S. This is
currently done by checking ifor 'phdr-&gt;p_paddr == 0'. This works fine for
the current kernel build but in theory the first few pages could be
skipped. Make the detection more robust by checking if the entry point lies
within the segment.

Signed-off-by: Philipp Rudo &lt;prudo@linux.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>s390/speculation: Support 'mitigations=' cmdline option</title>
<updated>2019-05-14T17:17:13Z</updated>
<author>
<name>Josh Poimboeuf</name>
</author>
<published>2019-04-12T20:39:31Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=394e3d8de828de254218b2c183a5858d037facf5'/>
<id>urn:sha1:394e3d8de828de254218b2c183a5858d037facf5</id>
<content type='text'>
commit 0336e04a6520bdaefdb0769d2a70084fa52e81ed upstream

Configure s390 runtime CPU speculation bug mitigations in accordance
with the 'mitigations=' cmdline option.  This affects Spectre v1 and
Spectre v2.

The default behavior is unchanged.

Signed-off-by: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Jiri Kosina &lt;jkosina@suse.cz&gt; (on x86)
Reviewed-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Cc: Borislav Petkov &lt;bp@alien8.de&gt;
Cc: "H . Peter Anvin" &lt;hpa@zytor.com&gt;
Cc: Andy Lutomirski &lt;luto@kernel.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Jiri Kosina &lt;jikos@kernel.org&gt;
Cc: Waiman Long &lt;longman@redhat.com&gt;
Cc: Andrea Arcangeli &lt;aarcange@redhat.com&gt;
Cc: Jon Masters &lt;jcm@redhat.com&gt;
Cc: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Cc: Paul Mackerras &lt;paulus@samba.org&gt;
Cc: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Cc: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Cc: linux-s390@vger.kernel.org
Cc: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Cc: Will Deacon &lt;will.deacon@arm.com&gt;
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-arch@vger.kernel.org
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: Tyler Hicks &lt;tyhicks@canonical.com&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Cc: Steven Price &lt;steven.price@arm.com&gt;
Cc: Phil Auld &lt;pauld@redhat.com&gt;
Link: https://lkml.kernel.org/r/e4a161805458a5ec88812aac0307ae3908a030fc.1555085500.git.jpoimboe@redhat.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>perf/aux: Make perf_event accessible to setup_aux()</title>
<updated>2019-04-05T20:34:42Z</updated>
<author>
<name>Mathieu Poirier</name>
</author>
<published>2019-01-31T18:47:08Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4e4fba6d30f830fec0bc40cbb174b3af86370f95'/>
<id>urn:sha1:4e4fba6d30f830fec0bc40cbb174b3af86370f95</id>
<content type='text'>
[ Upstream commit 840018668ce2d96783356204ff282d6c9b0e5f66 ]

When pmu::setup_aux() is called the coresight PMU needs to know which
sink to use for the session by looking up the information in the
event's attr::config2 field.

As such simply replace the cpu information by the complete perf_event
structure and change all affected customers.

Signed-off-by: Mathieu Poirier &lt;mathieu.poirier@linaro.org&gt;
Reviewed-by: Suzuki Poulouse &lt;suzuki.poulose@arm.com&gt;
Acked-by: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Adrian Hunter &lt;adrian.hunter@intel.com&gt;
Cc: Alexander Shishkin &lt;alexander.shishkin@linux.intel.com&gt;
Cc: Alexei Starovoitov &lt;ast@kernel.org&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: H. Peter Anvin &lt;hpa@zytor.com&gt;
Cc: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Cc: Jiri Olsa &lt;jolsa@redhat.com&gt;
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Will Deacon &lt;will.deacon@arm.com&gt;
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-s390@vger.kernel.org
Link: http://lkml.kernel.org/r/20190131184714.20388-2-mathieu.poirier@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>s390/setup: fix boot crash for machine without EDAT-1</title>
<updated>2019-03-23T19:11:41Z</updated>
<author>
<name>Martin Schwidefsky</name>
</author>
<published>2019-02-18T17:10:08Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1b2f5d715bbc21c548c834647084c4ad7952696f'/>
<id>urn:sha1:1b2f5d715bbc21c548c834647084c4ad7952696f</id>
<content type='text'>
commit 86a86804e4f18fc3880541b3d5a07f4df0fe29cb upstream.

The fix to make WARN work in the early boot code created a problem
on older machines without EDAT-1. The setup_lowcore_dat_on function
uses the pointer from lowcore_ptr[0] to set the DAT bit in the new
PSWs. That does not work if the kernel page table is set up with
4K pages as the prefix address maps to absolute zero.

To make this work the PSWs need to be changed with via address 0 in
form of the S390_lowcore definition.

Reported-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Tested-by: Cornelia Huck &lt;cohuck@redhat.com&gt;
Fixes: 94f85ed3e2f8 ("s390/setup: fix early warning messages")
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>s390/setup: fix early warning messages</title>
<updated>2019-03-23T19:11:20Z</updated>
<author>
<name>Martin Schwidefsky</name>
</author>
<published>2019-02-14T14:40:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=39fdc16138b799d2603d9b18ba4d4059df8f54cc'/>
<id>urn:sha1:39fdc16138b799d2603d9b18ba4d4059df8f54cc</id>
<content type='text'>
commit 8727638426b0aea59d7f904ad8ddf483f9234f88 upstream.

The setup_lowcore() function creates a new prefix page for the boot CPU.
The PSW mask for the system_call, external interrupt, i/o interrupt and
the program check handler have the DAT bit set in this new prefix page.

At the time setup_lowcore is called the system still runs without virtual
address translation, the paging_init() function creates the kernel page
table and loads the CR13 with the kernel ASCE.

Any code between setup_lowcore() and the end of paging_init() that has
a BUG or WARN statement will create a program check that can not be
handled correctly as there is no kernel page table yet.

To allow early WARN statements initially setup the lowcore with DAT off
and set the DAT bit only after paging_init() has completed.

Cc: stable@vger.kernel.org
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>s390/suspend: fix stack setup in swsusp_arch_suspend</title>
<updated>2019-01-28T14:43:17Z</updated>
<author>
<name>Martin Schwidefsky</name>
</author>
<published>2019-01-17T10:20:28Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=634692ab7007e8e3fec758ab0b26e65abf7c79e0'/>
<id>urn:sha1:634692ab7007e8e3fec758ab0b26e65abf7c79e0</id>
<content type='text'>
The patch that added support for the virtually mapped kernel stacks changed
swsusp_arch_suspend to switch to the nodat-stack as the vmap stack is not
available while going in and out of suspend.

Unfortunately the switch to the nodat-stack is incorrect which breaks
suspend to disk.

Cc: stable@vger.kernel.org # v4.20
Fixes: ce3dc447493f ("s390: add support for virtually mapped kernel stacks")
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/smp: Fix calling smp_call_ipl_cpu() from ipl CPU</title>
<updated>2019-01-11T16:12:03Z</updated>
<author>
<name>David Hildenbrand</name>
</author>
<published>2019-01-11T14:18:22Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=60f1bf29c0b2519989927cae640cd1f50f59dc7f'/>
<id>urn:sha1:60f1bf29c0b2519989927cae640cd1f50f59dc7f</id>
<content type='text'>
When calling smp_call_ipl_cpu() from the IPL CPU, we will try to read
from pcpu_devices-&gt;lowcore. However, due to prefixing, that will result
in reading from absolute address 0 on that CPU. We have to go via the
actual lowcore instead.

This means that right now, we will read lc-&gt;nodat_stack == 0 and
therfore work on a very wrong stack.

This BUG essentially broke rebooting under QEMU TCG (which will report
a low address protection exception). And checking under KVM, it is
also broken under KVM. With 1 VCPU it can be easily triggered.

:/# echo 1 &gt; /proc/sys/kernel/sysrq
:/# echo b &gt; /proc/sysrq-trigger
[   28.476745] sysrq: SysRq : Resetting
[   28.476793] Kernel stack overflow.
[   28.476817] CPU: 0 PID: 424 Comm: sh Not tainted 5.0.0-rc1+ #13
[   28.476820] Hardware name: IBM 2964 NE1 716 (KVM/Linux)
[   28.476826] Krnl PSW : 0400c00180000000 0000000000115c0c (pcpu_delegate+0x12c/0x140)
[   28.476861]            R:0 T:1 IO:0 EX:0 Key:0 M:0 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3
[   28.476863] Krnl GPRS: ffffffffffffffff 0000000000000000 000000000010dff8 0000000000000000
[   28.476864]            0000000000000000 0000000000000000 0000000000ab7090 000003e0006efbf0
[   28.476864]            000000000010dff8 0000000000000000 0000000000000000 0000000000000000
[   28.476865]            000000007fffc000 0000000000730408 000003e0006efc58 0000000000000000
[   28.476887] Krnl Code: 0000000000115bfe: 4170f000            la      %r7,0(%r15)
[   28.476887]            0000000000115c02: 41f0a000            la      %r15,0(%r10)
[   28.476887]           #0000000000115c06: e370f0980024        stg     %r7,152(%r15)
[   28.476887]           &gt;0000000000115c0c: c0e5fffff86e        brasl   %r14,114ce8
[   28.476887]            0000000000115c12: 41f07000            la      %r15,0(%r7)
[   28.476887]            0000000000115c16: a7f4ffa8            brc     15,115b66
[   28.476887]            0000000000115c1a: 0707                bcr     0,%r7
[   28.476887]            0000000000115c1c: 0707                bcr     0,%r7
[   28.476901] Call Trace:
[   28.476902] Last Breaking-Event-Address:
[   28.476920]  [&lt;0000000000a01c4a&gt;] arch_call_rest_init+0x22/0x80
[   28.476927] Kernel panic - not syncing: Corrupt kernel stack, can't continue.
[   28.476930] CPU: 0 PID: 424 Comm: sh Not tainted 5.0.0-rc1+ #13
[   28.476932] Hardware name: IBM 2964 NE1 716 (KVM/Linux)
[   28.476932] Call Trace:

Fixes: 2f859d0dad81 ("s390/smp: reduce size of struct pcpu")
Cc: stable@vger.kernel.org # 4.0+
Reported-by: Cornelia Huck &lt;cohuck@redhat.com&gt;
Signed-off-by: David Hildenbrand &lt;david@redhat.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/vdso: correct vdso mapping for compat tasks</title>
<updated>2019-01-11T16:12:02Z</updated>
<author>
<name>Vasily Gorbik</name>
</author>
<published>2019-01-02T12:43:22Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=190f056fba230abee80712eb810939ef9a8c462f'/>
<id>urn:sha1:190f056fba230abee80712eb810939ef9a8c462f</id>
<content type='text'>
While "s390/vdso: avoid 64-bit vdso mapping for compat tasks" fixed
64-bit vdso mapping for compat tasks under gdb it introduced another
problem. "compat_mm" flag is not inherited during fork and when
31-bit process forks a child (but does not perform exec) it ends up
with 64-bit vdso. To address that, init_new_context (which is called
during fork and exec) now initialize compat_mm based on thread TIF_31BIT
flag. Later compat_mm is adjusted in arch_setup_additional_pages, which
is called during exec.

Fixes: d1befa65823e ("s390/vdso: avoid 64-bit vdso mapping for compat tasks")
Reported-by: Stefan Liebler &lt;stli@linux.ibm.com&gt;
Reviewed-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.20+
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/smp: fix CPU hotplug deadlock with CPU rescan</title>
<updated>2019-01-11T16:12:02Z</updated>
<author>
<name>Gerald Schaefer</name>
</author>
<published>2019-01-09T12:00:03Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b7cb707c373094ce4008d4a6ac9b6b366ec52da5'/>
<id>urn:sha1:b7cb707c373094ce4008d4a6ac9b6b366ec52da5</id>
<content type='text'>
smp_rescan_cpus() is called without the device_hotplug_lock, which can lead
to a dedlock when a new CPU is found and immediately set online by a udev
rule.

This was observed on an older kernel version, where the cpu_hotplug_begin()
loop was still present, and it resulted in hanging chcpu and systemd-udev
processes. This specific deadlock will not show on current kernels. However,
there may be other possible deadlocks, and since smp_rescan_cpus() can still
trigger a CPU hotplug operation, the device_hotplug_lock should be held.

For reference, this was the deadlock with the old cpu_hotplug_begin() loop:

        chcpu (rescan)                       systemd-udevd

 echo 1 &gt; /sys/../rescan
 -&gt; smp_rescan_cpus()
 -&gt; (*) get_online_cpus()
    (increases refcount)
 -&gt; smp_add_present_cpu()
    (new CPU found)
 -&gt; register_cpu()
 -&gt; device_add()
 -&gt; udev "add" event triggered -----------&gt; udev rule sets CPU online
                                         -&gt; echo 1 &gt; /sys/.../online
                                         -&gt; lock_device_hotplug_sysfs()
                                            (this is missing in rescan path)
                                         -&gt; device_online()
                                         -&gt; (**) device_lock(new CPU dev)
                                         -&gt; cpu_up()
                                         -&gt; cpu_hotplug_begin()
                                            (loops until refcount == 0)
                                            -&gt; deadlock with (*)
 -&gt; bus_probe_device()
 -&gt; device_attach()
 -&gt; device_lock(new CPU dev)
    -&gt; deadlock with (**)

Fix this by taking the device_hotplug_lock in the CPU rescan path.

Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Gerald Schaefer &lt;gerald.schaefer@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/early: improve machine detection</title>
<updated>2019-01-11T16:12:02Z</updated>
<author>
<name>Christian Borntraeger</name>
</author>
<published>2018-11-09T08:21:47Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=03aa047ef2db4985e444af6ee1c1dd084ad9fb4c'/>
<id>urn:sha1:03aa047ef2db4985e444af6ee1c1dd084ad9fb4c</id>
<content type='text'>
Right now the early machine detection code check stsi 3.2.2 for "KVM"
and set MACHINE_IS_VM if this is different. As the console detection
uses diagnose 8 if MACHINE_IS_VM returns true this will crash Linux
early for any non z/VM system that sets a different value than KVM.
So instead of assuming z/VM, do not set any of MACHINE_IS_LPAR,
MACHINE_IS_VM, or MACHINE_IS_KVM.

CC: stable@vger.kernel.org
Reviewed-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
</content>
</entry>
</feed>
