<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/s390, 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/Kconfig: add missing ZCRYPT dependency to VFIO_AP</title>
<updated>2020-08-21T11:07:41Z</updated>
<author>
<name>Krzysztof Kozlowski</name>
</author>
<published>2020-08-05T15:50:53Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=fdeb41184c3283bc7019c44b619de9fe8688e598'/>
<id>urn:sha1:fdeb41184c3283bc7019c44b619de9fe8688e598</id>
<content type='text'>
[ Upstream commit 929a343b858612100cb09443a8aaa20d4a4706d3 ]

The VFIO_AP uses ap_driver_register() (and deregister) functions
implemented in ap_bus.c (compiled into ap.o).  However the ap.o will be
built only if CONFIG_ZCRYPT is selected.

This was not visible before commit e93a1695d7fb ("iommu: Enable compile
testing for some of drivers") because the CONFIG_VFIO_AP depends on
CONFIG_S390_AP_IOMMU which depends on the missing CONFIG_ZCRYPT.  After
adding COMPILE_TEST, it is possible to select a configuration with
VFIO_AP and S390_AP_IOMMU but without the ZCRYPT.

Add proper dependency to the VFIO_AP to fix build errors:

ERROR: modpost: "ap_driver_register" [drivers/s390/crypto/vfio_ap.ko] undefined!
ERROR: modpost: "ap_driver_unregister" [drivers/s390/crypto/vfio_ap.ko] undefined!

Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Fixes: e93a1695d7fb ("iommu: Enable compile testing for some of drivers")
Signed-off-by: Krzysztof Kozlowski &lt;krzk@kernel.org&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/test_unwind: fix possible memleak in test_unwind()</title>
<updated>2020-08-21T11:07:41Z</updated>
<author>
<name>Wang Hai</name>
</author>
<published>2020-07-30T06:36:02Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=07a4dc1435820ef9fcbb9767a0239336d24ca9bf'/>
<id>urn:sha1:07a4dc1435820ef9fcbb9767a0239336d24ca9bf</id>
<content type='text'>
[ Upstream commit 75d3e7f4769d276a056efa1cc7f08de571fc9b4b ]

test_unwind() misses to call kfree(bt) in an error path.
Add the missed function call to fix it.

Fixes: 0610154650f1 ("s390/test_unwind: print verbose unwinding results")
Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Signed-off-by: Wang Hai &lt;wanghai38@huawei.com&gt;
Acked-by: Ilya Leoshkevich &lt;iii@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/gmap: improve THP splitting</title>
<updated>2020-08-19T06:24:19Z</updated>
<author>
<name>Gerald Schaefer</name>
</author>
<published>2020-07-29T20:22:34Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2c3efa09c6eec4d6fdd8bb76caa45b8fed40e8ad'/>
<id>urn:sha1:2c3efa09c6eec4d6fdd8bb76caa45b8fed40e8ad</id>
<content type='text'>
commit ba925fa35057a062ac98c3e8138b013ce4ce351c upstream.

During s390_enable_sie(), we need to take care of splitting all qemu user
process THP mappings. This is currently done with follow_page(FOLL_SPLIT),
by simply iterating over all vma ranges, with PAGE_SIZE increment.

This logic is sub-optimal and can result in a lot of unnecessary overhead,
especially when using qemu and ASAN with large shadow map. Ilya reported
significant system slow-down with one CPU busy for a long time and overall
unresponsiveness.

Fix this by using walk_page_vma() and directly calling split_huge_pmd()
only for present pmds, which greatly reduces overhead.

Cc: &lt;stable@vger.kernel.org&gt; # v5.4+
Reported-by: Ilya Leoshkevich &lt;iii@linux.ibm.com&gt;
Tested-by: Ilya Leoshkevich &lt;iii@linux.ibm.com&gt;
Acked-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Signed-off-by: Gerald Schaefer &lt;gerald.schaefer@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/numa: set node distance to LOCAL_DISTANCE</title>
<updated>2020-08-19T06:24:19Z</updated>
<author>
<name>Alexander Gordeev</name>
</author>
<published>2020-08-04T18:35:49Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=16de2abbc0713caded7f84e8ccd8991ae99687a1'/>
<id>urn:sha1:16de2abbc0713caded7f84e8ccd8991ae99687a1</id>
<content type='text'>
commit 535e4fc623fab2e09a0653fc3a3e17f382ad0251 upstream.

The node distance is hardcoded to 0, which causes a trouble
for some user-level applications. In particular, "libnuma"
expects the distance of a node to itself as LOCAL_DISTANCE.
This update removes the offending node distance override.

Cc: &lt;stable@vger.kernel.org&gt; # 4.4
Fixes: 3a368f742da1 ("s390/numa: add core infrastructure")
Signed-off-by: Alexander Gordeev &lt;agordeev@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/bpf: Tolerate not converging code shrinking</title>
<updated>2020-08-19T06:23:59Z</updated>
<author>
<name>Ilya Leoshkevich</name>
</author>
<published>2020-07-17T16:53:25Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ff3e1a7d43e8f06aa839ac5f6b0c742750054b73'/>
<id>urn:sha1:ff3e1a7d43e8f06aa839ac5f6b0c742750054b73</id>
<content type='text'>
[ Upstream commit 1491b73311a15bb5beeab5d30e03bff761ef6c18 ]

"BPF_MAXINSNS: Maximum possible literals" unnecessarily falls back to
the interpreter because of failing sanity check in bpf_set_addr. The
problem is that there are a lot of branches that can be shrunk, and
doing so opens up the possibility to shrink even more. This process
does not converge after 3 passes, causing code offsets to change during
the codegen pass, which must never happen.

Fix by inserting nops during codegen pass in order to preserve code
offets.

Fixes: 4e9b4a6883dd ("s390/bpf: Use relative long branches")
Signed-off-by: Ilya Leoshkevich &lt;iii@linux.ibm.com&gt;
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
Link: https://lore.kernel.org/bpf/20200717165326.6786-5-iii@linux.ibm.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>s390/bpf: Use brcl for jumping to exit_ip if necessary</title>
<updated>2020-08-19T06:23:59Z</updated>
<author>
<name>Ilya Leoshkevich</name>
</author>
<published>2020-07-17T16:53:24Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b5f48c957f335c8d97fd554fd08c73f6dbfb001a'/>
<id>urn:sha1:b5f48c957f335c8d97fd554fd08c73f6dbfb001a</id>
<content type='text'>
[ Upstream commit 5fa6974471c5518a50bdd814067508dbcb477251 ]

"BPF_MAXINSNS: Maximum possible literals" test causes panic with
bpf_jit_harden = 2. The reason is that BPF_JMP | BPF_EXIT is always
emitted as brc, however, after removal of JITed image size
limitations, brcl might be required.

Fix by using brcl when necessary.

Fixes: 4e9b4a6883dd ("s390/bpf: Use relative long branches")
Signed-off-by: Ilya Leoshkevich &lt;iii@linux.ibm.com&gt;
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
Link: https://lore.kernel.org/bpf/20200717165326.6786-4-iii@linux.ibm.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>s390/bpf: Fix sign extension in branch_ku</title>
<updated>2020-08-19T06:23:58Z</updated>
<author>
<name>Ilya Leoshkevich</name>
</author>
<published>2020-07-17T16:53:23Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c3472775e1fb949e8bd365239f156186d1a97d11'/>
<id>urn:sha1:c3472775e1fb949e8bd365239f156186d1a97d11</id>
<content type='text'>
[ Upstream commit 7477d43be5b1448bc0d4c85cb185a0144cc080e1 ]

Both signed and unsigned variants of BPF_JMP | BPF_K require
sign-extending the immediate. JIT emits cgfi for the signed case,
which is correct, and clgfi for the unsigned case, which is not
correct: clgfi zero-extends the immediate.

s390 does not provide an instruction that does sign-extension and
unsigned comparison at the same time. Therefore, fix by first loading
the sign-extended immediate into work register REG_1 and proceeding
as if it's BPF_X.

Fixes: 4e9b4a6883dd ("s390/bpf: Use relative long branches")
Reported-by: Seth Forshee &lt;seth.forshee@canonical.com&gt;
Signed-off-by: Ilya Leoshkevich &lt;iii@linux.ibm.com&gt;
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
Tested-by: Seth Forshee &lt;seth.forshee@canonical.com&gt;
Link: https://lore.kernel.org/bpf/20200717165326.6786-3-iii@linux.ibm.com
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>
</feed>
