<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/s390/boot, branch linux-5.13.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.13.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.13.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2021-07-28T12:37:34Z</updated>
<entry>
<title>s390/boot: fix use of expolines in the DMA code</title>
<updated>2021-07-28T12:37:34Z</updated>
<author>
<name>Alexander Egorenkov</name>
</author>
<published>2021-07-16T20:00:22Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ca4c5e5c7bebe30de6048c1f65fb22a659393cce'/>
<id>urn:sha1:ca4c5e5c7bebe30de6048c1f65fb22a659393cce</id>
<content type='text'>
commit 463f36c76fa4ec015c640ff63ccf52e7527abee0 upstream.

The DMA code section of the decompressor must be compiled with expolines
if Spectre V2 mitigation has been enabled for the decompressed kernel.
This is required because although the decompressor's image contains
the DMA code section, it is handed over to the decompressed kernel for use.

Because the DMA code is already slow w/o expolines, use expolines always
regardless whether the decompressed kernel is using them or not. This
simplifies the DMA code by dropping the conditional compilation of
expolines.

Fixes: bf72630130c2 ("s390: use proper expoline sections for .dma code")
Cc: &lt;stable@vger.kernel.org&gt; # 5.2
Signed-off-by: Alexander Egorenkov &lt;egorenar@linux.ibm.com&gt;
Reviewed-by: Heiko Carstens &lt;hca@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/mem_detect: fix tprot() program check new psw handling</title>
<updated>2021-07-20T14:00:20Z</updated>
<author>
<name>Heiko Carstens</name>
</author>
<published>2021-06-14T20:09:20Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1043c57cff3d055866baa6a85dc06e593a582f8e'/>
<id>urn:sha1:1043c57cff3d055866baa6a85dc06e593a582f8e</id>
<content type='text'>
[ Upstream commit da9057576785aaab52e706e76c0475c85b77ec14 ]

The tprot() inline asm temporarily changes the program check new psw
to redirect a potential program check on the diag instruction.
Restoring of the program check new psw is done in C code behind the
inline asm.

This can be problematic, especially if the function is inlined, since
the compiler can reorder instructions in such a way that a different
instruction, which may result in a program check, might be executed
before the program check new psw has been restored.

To avoid such a scenario move restoring into the inline asm. For
consistency reasons move also saving of the original program check new
psw into the inline asm.

Signed-off-by: Heiko Carstens &lt;hca@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/mem_detect: fix diag260() program check new psw handling</title>
<updated>2021-07-20T14:00:20Z</updated>
<author>
<name>Heiko Carstens</name>
</author>
<published>2021-06-14T19:40:43Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bf04c373f1b30f0b443f6e36c33fa090cf3708c7'/>
<id>urn:sha1:bf04c373f1b30f0b443f6e36c33fa090cf3708c7</id>
<content type='text'>
[ Upstream commit 86807f348f418a84970eebb8f9912a7eea16b497 ]

The __diag260() inline asm temporarily changes the program check new
psw to redirect a potential program check on the diag instruction.
Restoring of the program check new psw is done in C code behind the
inline asm.

This can be problematic, especially if the function is inlined, since
the compiler can reorder instructions in such a way that a different
instruction, which may result in a program check, might be executed
before the program check new psw has been restored.

To avoid such a scenario move restoring into the inline asm. For
consistency reasons move also saving of the original program check new
psw into the inline asm.

Signed-off-by: Heiko Carstens &lt;hca@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/ipl_parm: fix program check new psw handling</title>
<updated>2021-07-20T14:00:19Z</updated>
<author>
<name>Heiko Carstens</name>
</author>
<published>2021-06-14T12:49:31Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5c80766b911d3d7f4326bba2fedf415064292cce'/>
<id>urn:sha1:5c80766b911d3d7f4326bba2fedf415064292cce</id>
<content type='text'>
[ Upstream commit 88c2510cecb7e2b518e3c4fdf3cf0e13ebe9377c ]

The __diag308() inline asm temporarily changes the program check new
psw to redirect a potential program check on the diag instruction.
Restoring of the program check new psw is done in C code behind the
inline asm.

This can be problematic, especially if the function is inlined, since
the compiler can reorder instructions in such a way that a different
instruction, which may result in a program check, might be executed
before the program check new psw has been restored.

To avoid such a scenario move restoring into the inline asm. For
consistency reasons move also saving of the original program check new
psw into the inline asm.

Signed-off-by: Heiko Carstens &lt;hca@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: mm: Fix secure storage access exception handling</title>
<updated>2021-07-14T15:06:13Z</updated>
<author>
<name>Janosch Frank</name>
</author>
<published>2021-01-12T10:40:53Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1254698f9d631fd67ecdf076a45cc09a226969af'/>
<id>urn:sha1:1254698f9d631fd67ecdf076a45cc09a226969af</id>
<content type='text'>
commit 85b18d7b5e7ffefb2f076186511d39c4990aa005 upstream.

Turns out that the bit 61 in the TEID is not always 1 and if that's
the case the address space ID and the address are
unpredictable. Without an address and its address space ID we can't
export memory and hence we can only send a SIGSEGV to the process or
panic the kernel depending on who caused the exception.

Unfortunately bit 61 is only reliable if we have the "misc" UV feature
bit.

Signed-off-by: Janosch Frank &lt;frankja@linux.ibm.com&gt;
Reviewed-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Fixes: 084ea4d611a3d ("s390/mm: add (non)secure page access exceptions handlers")
Cc: stable@vger.kernel.org
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>s390: uv: Fix sysfs max number of VCPUs reporting</title>
<updated>2021-01-27T12:00:04Z</updated>
<author>
<name>Janosch Frank</name>
</author>
<published>2021-01-13T16:56:26Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e82080e1f456467cc185fe65ee69fe9f9bd0b576'/>
<id>urn:sha1:e82080e1f456467cc185fe65ee69fe9f9bd0b576</id>
<content type='text'>
The number reported by the query is N-1 and I think people reading the
sysfs file would expect N instead. For users creating VMs there's no
actual difference because KVM's limit is currently below the UV's
limit.

Signed-off-by: Janosch Frank &lt;frankja@linux.ibm.com&gt;
Fixes: a0f60f8431999 ("s390/protvirt: Add sysfs firmware interface for Ultravisor information")
Cc: stable@vger.kernel.org
Reviewed-by: Claudio Imbrenda &lt;imbrenda@linux.ibm.com&gt;
Acked-by: Cornelia Huck &lt;cohuck@redhat.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>kasan, x86, s390: update undef CONFIG_KASAN</title>
<updated>2020-12-22T20:55:08Z</updated>
<author>
<name>Andrey Konovalov</name>
</author>
<published>2020-12-22T20:02:03Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8a494023b80e29bb3638be18a6710a1c884ee68e'/>
<id>urn:sha1:8a494023b80e29bb3638be18a6710a1c884ee68e</id>
<content type='text'>
With the intoduction of hardware tag-based KASAN some kernel checks of
this kind:

  ifdef CONFIG_KASAN

will be updated to:

  if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)

x86 and s390 use a trick to #undef CONFIG_KASAN for some of the code
that isn't linked with KASAN runtime and shouldn't have any KASAN
annotations.

Also #undef CONFIG_KASAN_GENERIC with CONFIG_KASAN.

Link: https://lkml.kernel.org/r/9d84bfaaf8fabe0fc89f913c9e420a30bd31a260.1606161801.git.andreyknvl@google.com
Signed-off-by: Andrey Konovalov &lt;andreyknvl@google.com&gt;
Signed-off-by: Vincenzo Frascino &lt;vincenzo.frascino@arm.com&gt;
Reviewed-by: Marco Elver &lt;elver@google.com&gt;
Acked-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Reviewed-by: Alexander Potapenko &lt;glider@google.com&gt;
Tested-by: Vincenzo Frascino &lt;vincenzo.frascino@arm.com&gt;
Cc: Andrey Ryabinin &lt;aryabinin@virtuozzo.com&gt;
Cc: Branislav Rankov &lt;Branislav.Rankov@arm.com&gt;
Cc: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Cc: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Cc: Evgenii Stepanov &lt;eugenis@google.com&gt;
Cc: Kevin Brodsky &lt;kevin.brodsky@arm.com&gt;
Cc: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>s390/boot: add build-id to decompressor</title>
<updated>2020-12-09T20:02:07Z</updated>
<author>
<name>Philipp Rudo</name>
</author>
<published>2020-11-25T18:08:23Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7a84ffc0471f0ff59f9ae10807a77bd666e24fd0'/>
<id>urn:sha1:7a84ffc0471f0ff59f9ae10807a77bd666e24fd0</id>
<content type='text'>
More and more functionality from the early boot phase gets carried over
to the decompressor. With this the complexity of the code and thus the
chance to introduce bugs increases. In order to be able to debug these
early boot bugs the distributions have to package the decompressors
vmlinux together with the other debuginfos. However for that the
distributions require the vmlinux to contain a build-id.

Per default the section containing the build-id is placed first in the
section table. So make sure to move it behind the .text section
otherwise the image would be unbootable.

Signed-off-by: Philipp Rudo &lt;prudo@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/decompressor: print cmdline and BEAR on pgm_check</title>
<updated>2020-11-20T18:19:11Z</updated>
<author>
<name>Vasily Gorbik</name>
</author>
<published>2020-11-10T22:30:23Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ba1a6be994e8444baf23c14d7be045811197ccb3'/>
<id>urn:sha1:ba1a6be994e8444baf23c14d7be045811197ccb3</id>
<content type='text'>
Add kernel command line and last breaking event.
The kernel command line is taken from early_command_line and printed
only if kernel is not running as protected virtualization guest and
if it has been already initialized from the "COMMAND_LINE".

Linux version 5.10.0-rc3-22794-gecaa72788df0-dirty (gor@tuxmaker) #28 SMP PREEMPT Mon Nov 9 17:41:20 CET 2020
Kernel command line: audit_enable=0 audit=0 selinux=0 crashkernel=296M root=/dev/dasda1 dasd=ec5b
memblock=debug die
Kernel fault: interruption code 0005 ilc:2
PSW : 0000000180000000 0000000000012f92 (parse_boot_command_line+0x27a/0x46c)
      R:0 T:0 IO:0 EX:0 Key:0 M:0 W:0 P:0 AS:0 CC:0 PM:0 RI:0 EA:3
GPRS: 0000000000000000 00ffffffffffffff 0000000000000000 000000000001a65c
      000000000000bf60 0000000000000000 00000000000003c0 0000000000000000
      0000000000000080 000000000002322d 000000007f29ef20 0000000000efd018
      000000000311c000 0000000000010070 0000000000012f82 000000000000bea8
Call Trace:
(sp:000000000000bea8 [&lt;000000000002016e&gt;] 000000000002016e)
 sp:000000000000bf18 [&lt;0000000000012408&gt;] startup_kernel+0x88/0x2fc
 sp:000000000000bf60 [&lt;00000000000100c4&gt;] startup_normal+0xb0/0xb0
Last Breaking-Event-Address:
 [&lt;00000000000135ba&gt;] strcmp+0x22/0x24

Reviewed-by: Alexander Egorenkov &lt;egorenar@linux.ibm.com&gt;
Acked-by: Viktor Mihajlovski &lt;mihajlov@linux.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/decompressor: add stacktrace support</title>
<updated>2020-11-20T18:19:11Z</updated>
<author>
<name>Vasily Gorbik</name>
</author>
<published>2020-11-10T16:05:35Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8977ab65b894d889c3919581bf545ed106a9a1a5'/>
<id>urn:sha1:8977ab65b894d889c3919581bf545ed106a9a1a5</id>
<content type='text'>
Decompressor works on a single statically allocated stack. Stacktrace
implementation with -mbackchain just takes few lines of code.

Linux version 5.10.0-rc3-22793-g0f84a355b776-dirty (gor@tuxmaker) #27 SMP PREEMPT Mon Nov 9 17:30:18 CET 2020
Kernel fault: interruption code 0005 ilc:2
PSW : 0000000180000000 0000000000012f92 (parse_boot_command_line+0x27a/0x46c)
      R:0 T:0 IO:0 EX:0 Key:0 M:0 W:0 P:0 AS:0 CC:0 PM:0 RI:0 EA:3
GPRS: 0000000000000000 00ffffffffffffff 0000000000000000 000000000001a62c
      000000000000bf60 0000000000000000 00000000000003c0 0000000000000000
      0000000000000080 000000000002322d 000000007f29ef20 0000000000efd018
      000000000311c000 0000000000010070 0000000000012f82 000000000000bea8
Call Trace:
(sp:000000000000bea8 [&lt;000000000002016e&gt;] 000000000002016e)
 sp:000000000000bf18 [&lt;0000000000012408&gt;] startup_kernel+0x88/0x2fc
 sp:000000000000bf60 [&lt;00000000000100c4&gt;] startup_normal+0xb0/0xb0

Reviewed-by: Alexander Egorenkov &lt;egorenar@linux.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</content>
</entry>
</feed>
