<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/s390/kernel, branch linux-5.7.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.7.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.7.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2020-08-26T09:42:18Z</updated>
<entry>
<title>s390/ptrace: fix storage key handling</title>
<updated>2020-08-26T09:42:18Z</updated>
<author>
<name>Heiko Carstens</name>
</author>
<published>2020-08-12T16:56:28Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8cc038d59309458179bfddb70d41ab1c06b02d17'/>
<id>urn:sha1:8cc038d59309458179bfddb70d41ab1c06b02d17</id>
<content type='text'>
[ Upstream commit fd78c59446b8d050ecf3e0897c5a486c7de7c595 ]

The key member of the runtime instrumentation control block contains
only the access key, not the complete storage key. Therefore the value
must be shifted by four bits. Since existing user space does not
necessarily query and set the access key correctly, just ignore the
user space provided key and use the correct one.
Note: this is only relevant for debugging purposes in case somebody
compiles a kernel with a default storage access key set to a value not
equal to zero.

Fixes: 262832bc5acd ("s390/ptrace: add runtime instrumention register get/set")
Reported-by: Claudio Imbrenda &lt;imbrenda@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>s390/runtime_instrumentation: fix storage key handling</title>
<updated>2020-08-26T09:42:18Z</updated>
<author>
<name>Heiko Carstens</name>
</author>
<published>2020-08-12T16:55:41Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1ca48fa64aeda2ca090fe7d2e21fe9567b4e95a3'/>
<id>urn:sha1:1ca48fa64aeda2ca090fe7d2e21fe9567b4e95a3</id>
<content type='text'>
[ Upstream commit 9eaba29c7985236e16468f4e6a49cc18cf01443e ]

The key member of the runtime instrumentation control block contains
only the access key, not the complete storage key. Therefore the value
must be shifted by four bits.
Note: this is only relevant for debugging purposes in case somebody
compiles a kernel with a default storage access key set to a value not
equal to zero.

Fixes: e4b8b3f33fca ("s390: add support for runtime instrumentation")
Reported-by: Claudio Imbrenda &lt;imbrenda@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>s390/cpum_cf,perf: change DFLT_CCERROR counter name</title>
<updated>2020-07-29T08:19:39Z</updated>
<author>
<name>Thomas Richter</name>
</author>
<published>2020-07-17T09:27:22Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bd41890c879884de40aa8b61e34d609db67a4fef'/>
<id>urn:sha1:bd41890c879884de40aa8b61e34d609db67a4fef</id>
<content type='text'>
commit 3d3af181d370069861a3be94608464e2ff3682e2 upstream.

Change the counter name DLFT_CCERROR to DLFT_CCFINISH on IBM z15.
This counter counts completed DEFLATE instructions with exit code
0, 1 or 2. Since exit code 0 means success and exit code 1 or 2
indicate errors, change the counter name to avoid confusion.
This counter is incremented each time the DEFLATE instruction
completed regardless if an error was detected or not.

Fixes: d68d5d51dc89 ("s390/cpum_cf: Add new extended counters for IBM z15")
Fixes: e7950166e402 ("perf vendor events s390: Add new deflate counters for IBM z15")
Cc: stable@vger.kernel.org # v5.7
Signed-off-by: Thomas Richter &lt;tmricht@linux.ibm.com&gt;
Reviewed-by: Sumanth Korikkar &lt;sumanthk@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>s390/setup: init jump labels before command line parsing</title>
<updated>2020-07-16T06:13:34Z</updated>
<author>
<name>Vasily Gorbik</name>
</author>
<published>2020-06-18T15:17:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9dae3b787b69947c9270010789142ac6fec6b859'/>
<id>urn:sha1:9dae3b787b69947c9270010789142ac6fec6b859</id>
<content type='text'>
commit 95e61b1b5d6394b53d147c0fcbe2ae70fbe09446 upstream.

Command line parameters might set static keys. This is true for s390 at
least since commit 6471384af2a6 ("mm: security: introduce init_on_alloc=1
and init_on_free=1 boot options"). To avoid the following WARN:

static_key_enable_cpuslocked(): static key 'init_on_alloc+0x0/0x40' used
before call to jump_label_init()

call jump_label_init() just before parse_early_param().
jump_label_init() is safe to call multiple times (x86 does that), doesn't
do any memory allocations and hence should be safe to call that early.

Fixes: 6471384af2a6 ("mm: security: introduce init_on_alloc=1 and init_on_free=1 boot options")
Cc: &lt;stable@vger.kernel.org&gt; # 5.3: d6df52e9996d: s390/maccess: add no DAT mode to kernel_write
Cc: &lt;stable@vger.kernel.org&gt; # 5.3
Reviewed-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>s390/kasan: fix early pgm check handler execution</title>
<updated>2020-07-16T06:13:15Z</updated>
<author>
<name>Vasily Gorbik</name>
</author>
<published>2020-06-17T13:05:49Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b0a38eb0efcc15c2273c16c3eeb0f2e8531b7b2e'/>
<id>urn:sha1:b0a38eb0efcc15c2273c16c3eeb0f2e8531b7b2e</id>
<content type='text'>
[ Upstream commit 998f5bbe3dbdab81c1cfb1aef7c3892f5d24f6c7 ]

Currently if early_pgm_check_handler is called it ends up in pgm check
loop. The problem is that early_pgm_check_handler is instrumented by
KASAN but executed without DAT flag enabled which leads to addressing
exception when KASAN checks try to access shadow memory.

Fix that by executing early handlers with DAT flag on under KASAN as
expected.

Reported-and-tested-by: Alexander Egorenkov &lt;egorenar@linux.ibm.com&gt;
Reviewed-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>s390/debug: avoid kernel warning on too large number of pages</title>
<updated>2020-07-09T07:39:29Z</updated>
<author>
<name>Christian Borntraeger</name>
</author>
<published>2020-03-31T09:57:23Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=40a6a9fa77edd17c45dc34c4f258bb1c900522bd'/>
<id>urn:sha1:40a6a9fa77edd17c45dc34c4f258bb1c900522bd</id>
<content type='text'>
[ Upstream commit 827c4913923e0b441ba07ba4cc41e01181102303 ]

When specifying insanely large debug buffers a kernel warning is
printed. The debug code does handle the error gracefully, though.
Instead of duplicating the check let us silence the warning to
avoid crashes when panic_on_warn is used.

Signed-off-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Reviewed-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>s390/vdso: fix vDSO clock_getres()</title>
<updated>2020-06-30T19:36:17Z</updated>
<author>
<name>Vincenzo Frascino</name>
</author>
<published>2020-03-24T12:10:27Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=40b3e9c14a173859238f930f4696d6c12d9a2a6e'/>
<id>urn:sha1:40b3e9c14a173859238f930f4696d6c12d9a2a6e</id>
<content type='text'>
[ Upstream commit 478237a595120a18e9b52fd2c57a6e8b7a01e411 ]

clock_getres in the vDSO library has to preserve the same behaviour
of posix_get_hrtimer_res().

In particular, posix_get_hrtimer_res() does:
    sec = 0;
    ns = hrtimer_resolution;
and hrtimer_resolution depends on the enablement of the high
resolution timers that can happen either at compile or at run time.

Fix the s390 vdso implementation of clock_getres keeping a copy of
hrtimer_resolution in vdso data and using that directly.

Link: https://lkml.kernel.org/r/20200324121027.21665-1-vincenzo.frascino@arm.com
Signed-off-by: Vincenzo Frascino &lt;vincenzo.frascino@arm.com&gt;
Acked-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
[heiko.carstens@de.ibm.com: use llgf for proper zero extension]
Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>s390/vdso: Use $(LD) instead of $(CC) to link vDSO</title>
<updated>2020-06-30T19:36:17Z</updated>
<author>
<name>Nathan Chancellor</name>
</author>
<published>2020-06-02T19:25:24Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b671ec06830b79bd75a63d8051489a0c76269846'/>
<id>urn:sha1:b671ec06830b79bd75a63d8051489a0c76269846</id>
<content type='text'>
[ Upstream commit 2b2a25845d534ac6d55086e35c033961fdd83a26 ]

Currently, the VDSO is being linked through $(CC). This does not match
how the rest of the kernel links objects, which is through the $(LD)
variable.

When clang is built in a default configuration, it first attempts to use
the target triple's default linker, which is just ld. However, the user
can override this through the CLANG_DEFAULT_LINKER cmake define so that
clang uses another linker by default, such as LLVM's own linker, ld.lld.
This can be useful to get more optimized links across various different
projects.

However, this is problematic for the s390 vDSO because ld.lld does not
have any s390 emulatiom support:

https://github.com/llvm/llvm-project/blob/llvmorg-10.0.1-rc1/lld/ELF/Driver.cpp#L132-L150

Thus, if a user is using a toolchain with ld.lld as the default, they
will see an error, even if they have specified ld.bfd through the LD
make variable:

$ make -j"$(nproc)" -s ARCH=s390 CROSS_COMPILE=s390x-linux-gnu- LLVM=1 \
                       LD=s390x-linux-gnu-ld \
                       defconfig arch/s390/kernel/vdso64/
ld.lld: error: unknown emulation: elf64_s390
clang-11: error: linker command failed with exit code 1 (use -v to see invocation)

Normally, '-fuse-ld=bfd' could be used to get around this; however, this
can be fragile, depending on paths and variable naming. The cleaner
solution for the kernel is to take advantage of the fact that $(LD) can
be invoked directly, which bypasses the heuristics of $(CC) and respects
the user's choice. Similar changes have been done for ARM, ARM64, and
MIPS.

Link: https://lkml.kernel.org/r/20200602192523.32758-1-natechancellor@gmail.com
Link: https://github.com/ClangBuiltLinux/linux/issues/1041
Signed-off-by: Nathan Chancellor &lt;natechancellor@gmail.com&gt;
Reviewed-by: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
[heiko.carstens@de.ibm.com: add --build-id flag]
Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>s390/ptrace: fix setting syscall number</title>
<updated>2020-06-30T19:36:16Z</updated>
<author>
<name>Sven Schnelle</name>
</author>
<published>2020-03-09T15:44:50Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8797e1ca7dac6dd5b7ebcff608e6467e36a5562e'/>
<id>urn:sha1:8797e1ca7dac6dd5b7ebcff608e6467e36a5562e</id>
<content type='text'>
[ Upstream commit 873e5a763d604c32988c4a78913a8dab3862d2f9 ]

When strace wants to update the syscall number, it sets GPR2
to the desired number and updates the GPR via PTRACE_SETREGSET.
It doesn't update regs-&gt;int_code which would cause the old syscall
executed on syscall restart. As we cannot change the ptrace ABI and
don't have a field for the interruption code, check whether the tracee
is in a syscall and the last instruction was svc. In that case assume
that the tracer wants to update the syscall number and copy the GPR2
value to regs-&gt;int_code.

Signed-off-by: Sven Schnelle &lt;svens@linux.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>s390/ptrace: pass invalid syscall numbers to tracing</title>
<updated>2020-06-30T19:36:16Z</updated>
<author>
<name>Sven Schnelle</name>
</author>
<published>2020-03-06T12:19:34Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2b0111cf8ce035f9e292aeb31ec89cd6a3d88f4c'/>
<id>urn:sha1:2b0111cf8ce035f9e292aeb31ec89cd6a3d88f4c</id>
<content type='text'>
[ Upstream commit 00332c16b1604242a56289ff2b26e283dbad0812 ]

tracing expects to see invalid syscalls, so pass it through.
The syscall path in entry.S checks the syscall number before
looking up the handler, so it is still safe.

Signed-off-by: Sven Schnelle &lt;svens@linux.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
