<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/arch/s390, branch dev-4.10</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-4.10</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-4.10'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2017-04-27T07:12:58+00:00</updated>
<entry>
<title>s390/mm: fix CMMA vs KSM vs others</title>
<updated>2017-04-27T07:12:58+00:00</updated>
<author>
<name>Christian Borntraeger</name>
<email>borntraeger@de.ibm.com</email>
</author>
<published>2017-04-09T20:09:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=0cb760dfc75b16740dc47862806f8bb254f07b8e'/>
<id>urn:sha1:0cb760dfc75b16740dc47862806f8bb254f07b8e</id>
<content type='text'>
commit a8f60d1fadf7b8b54449fcc9d6b15248917478ba upstream.

On heavy paging with KSM I see guest data corruption. Turns out that
KSM will add pages to its tree, where the mapping return true for
pte_unused (or might become as such later).  KSM will unmap such pages
and reinstantiate with different attributes (e.g. write protected or
special, e.g. in replace_page or write_protect_page)). This uncovered
a bug in our pagetable handling: We must remove the unused flag as
soon as an entry becomes present again.

Signed-of-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
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/uaccess: get_user() should zero on failure (again)</title>
<updated>2017-04-12T10:42:08+00:00</updated>
<author>
<name>Heiko Carstens</name>
<email>heiko.carstens@de.ibm.com</email>
</author>
<published>2017-03-27T07:48:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=94f3dd6b140a2490f150340e7ace2ecb0dace28d'/>
<id>urn:sha1:94f3dd6b140a2490f150340e7ace2ecb0dace28d</id>
<content type='text'>
commit d09c5373e8e4eaaa09233552cbf75dc4c4f21203 upstream.

Commit fd2d2b191fe7 ("s390: get_user() should zero on failure")
intended to fix s390's get_user() implementation which did not zero
the target operand if the read from user space faulted. Unfortunately
the patch has no effect: the corresponding inline assembly specifies
that the operand is only written to ("=") and the previous value is
discarded.

Therefore the compiler is free to and actually does omit the zero
initialization.

To fix this simply change the contraint modifier to "+", so the
compiler cannot omit the initialization anymore.

Fixes: c9ca78415ac1 ("s390/uaccess: provide inline variants of get_user/put_user")
Fixes: fd2d2b191fe7 ("s390: get_user() should zero on failure")
Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
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/decompressor: fix initrd corruption caused by bss clear</title>
<updated>2017-04-12T10:42:08+00:00</updated>
<author>
<name>Marcelo Henrique Cerri</name>
<email>marcelo.cerri@canonical.com</email>
</author>
<published>2017-03-13T15:14:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=5d4d57697aa1cbb46b4954b7f09600d2bae0ac2c'/>
<id>urn:sha1:5d4d57697aa1cbb46b4954b7f09600d2bae0ac2c</id>
<content type='text'>
commit d82c0d12c92705ef468683c9b7a8298dd61ed191 upstream.

Reorder the operations in decompress_kernel() to ensure initrd is moved
to a safe location before the bss section is zeroed.

During decompression bss can overlap with the initrd and this can
corrupt the initrd contents depending on the size of the compressed
kernel (which affects where the initrd is placed by the bootloader) and
the size of the bss section of the decompressor.

Also use the correct initrd size when checking for overlaps with
parmblock.

Fixes: 06c0dd72aea3 ([S390] fix boot failures with compressed kernels)
Reviewed-by: Joy Latten &lt;joy.latten@canonical.com&gt;
Reviewed-by: Vineetha HariPai &lt;vineetha.hari.pai@canonical.com&gt;
Signed-off-by: Marcelo Henrique Cerri &lt;marcelo.cerri@canonical.com&gt;
Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
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>KVM: s390: Fix guest migration for huge guests resulting in panic</title>
<updated>2017-03-18T11:18:43+00:00</updated>
<author>
<name>Janosch Frank</name>
<email>frankja@linux.vnet.ibm.com</email>
</author>
<published>2017-03-02T14:23:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=1f9175b9ee7ca23995e377a05c3d93ac9457ab9c'/>
<id>urn:sha1:1f9175b9ee7ca23995e377a05c3d93ac9457ab9c</id>
<content type='text'>
commit 2e4d88009f57057df7672fa69a32b5224af54d37 upstream.

While we can technically not run huge page guests right now, we can
setup a guest with huge pages. Trying to migrate it will trigger a
VM_BUG_ON and, if the kernel is not configured to panic on a BUG, it
will happily try to work on non-existing page table entries.

With this patch, we always return "dirty" if we encounter a large page
when migrating. This at least fixes the immediate problem until we
have proper handling for both kind of pages.

Fixes: 15f36eb ("KVM: s390: Add proper dirty bitmap support to S390 kvm.")
Signed-off-by: Janosch Frank &lt;frankja@linux.vnet.ibm.com&gt;
Acked-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
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: use correct input data address for setup_randomness</title>
<updated>2017-03-15T02:20:08+00:00</updated>
<author>
<name>Heiko Carstens</name>
<email>heiko.carstens@de.ibm.com</email>
</author>
<published>2017-02-05T22:03:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=c9ac3e943deba05e17db732044e6ec44a29e0b7b'/>
<id>urn:sha1:c9ac3e943deba05e17db732044e6ec44a29e0b7b</id>
<content type='text'>
commit 4920e3cf77347d7d7373552d4839e8d832321313 upstream.

The current implementation of setup_randomness uses the stack address
and therefore the pointer to the SYSIB 3.2.2 block as input data
address. Furthermore the length of the input data is the number of
virtual-machine description blocks which is typically one.

This means that typically a single zero byte is fed to
add_device_randomness.

Fix both of these and use the address of the first virtual machine
description block as input data address and also use the correct
length.

Fixes: bcfcbb6bae64 ("s390: add system information as device randomness")
Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
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: make setup_randomness work</title>
<updated>2017-03-15T02:20:07+00:00</updated>
<author>
<name>Heiko Carstens</name>
<email>heiko.carstens@de.ibm.com</email>
</author>
<published>2017-02-04T10:40:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=0075504d83cefe2da69e1776956867ac368c4c3f'/>
<id>urn:sha1:0075504d83cefe2da69e1776956867ac368c4c3f</id>
<content type='text'>
commit da8fd820f389a0e29080b14c61bf5cf1d8ef5ca1 upstream.

Commit bcfcbb6bae64 ("s390: add system information as device
randomness") intended to add some virtual machine specific information
to the randomness pool.

Unfortunately it uses the page allocator before it is ready to use. In
result the page allocator always returns NULL and the setup_randomness
function never adds anything to the randomness pool.

To fix this use memblock_alloc and memblock_free instead.

Fixes: bcfcbb6bae64 ("s390: add system information as device randomness")
Signed-off-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
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/topology: correct allocation of topology information</title>
<updated>2017-03-15T02:20:07+00:00</updated>
<author>
<name>Martin Schwidefsky</name>
<email>schwidefsky@de.ibm.com</email>
</author>
<published>2017-02-04T11:38:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=ca54585dd5dd250fd61ab92ce192183ddc4d03f5'/>
<id>urn:sha1:ca54585dd5dd250fd61ab92ce192183ddc4d03f5</id>
<content type='text'>
commit 8676caa4fb7fc02b2c76842a0024919d0caa4b8d upstream.

The data stored by the STSI instruction can be up to a page in size
but the memblock_virt_alloc allocation for tl_info only specifies
16 bytes. The memory after the short allocation is overwritten
every time arch_update_cpu_topology is called.

Fixes: 8c9105802235 "s390/numa: establish cpu to node mapping early"
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: TASK_SIZE for kernel threads</title>
<updated>2017-03-15T02:20:07+00:00</updated>
<author>
<name>Martin Schwidefsky</name>
<email>schwidefsky@de.ibm.com</email>
</author>
<published>2017-02-24T06:43:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=c61a874ea0ec333c064cf97f379030e887360f17'/>
<id>urn:sha1:c61a874ea0ec333c064cf97f379030e887360f17</id>
<content type='text'>
commit fb94a687d96c570d46332a4a890f1dcb7310e643 upstream.

Return a sensible value if TASK_SIZE if called from a kernel thread.

This gets us around an issue with copy_mount_options that does a magic
size calculation "TASK_SIZE - (unsigned long)data" while in a kernel
thread and data pointing to kernel space.

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/kdump: Use "LINUX" ELF note name instead of "CORE"</title>
<updated>2017-03-15T02:20:07+00:00</updated>
<author>
<name>Michael Holzheu</name>
<email>holzheu@linux.vnet.ibm.com</email>
</author>
<published>2017-02-07T17:09:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=836f9814f09291e7404b57f774ee330f668a3bac'/>
<id>urn:sha1:836f9814f09291e7404b57f774ee330f668a3bac</id>
<content type='text'>
commit a4a81d8eebdc1d209d034f62a082a5131e4242b5 upstream.

In binutils/libbfd (bfd/elf.c) it is enforced that all s390 specific ELF
notes like e.g. NT_S390_PREFIX or NT_S390_CTRS have "LINUX" specified
as note name. Otherwise the notes are ignored.

For /proc/vmcore we currently use "CORE" for these notes.

Up to now this has not been a real problem because the dump analysis tool
"crash" does not check the note name. But it will break all programs that
use libbfd for processing ELF notes.

So fix this and use "LINUX" for all s390 specific notes to comply with
libbfd.

Reported-by: Philipp Rudo &lt;prudo@linux.vnet.ibm.com&gt;
Reviewed-by: Philipp Rudo &lt;prudo@linux.vnet.ibm.com&gt;
Signed-off-by: Michael Holzheu &lt;holzheu@linux.vnet.ibm.com&gt;
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>KVM: s390: Disable dirty log retrieval for UCONTROL guests</title>
<updated>2017-03-15T02:20:05+00:00</updated>
<author>
<name>Janosch Frank</name>
<email>frankja@linux.vnet.ibm.com</email>
</author>
<published>2017-02-02T15:39:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=f89d6db0c50caece69fe58089a02cf8dcc35842d'/>
<id>urn:sha1:f89d6db0c50caece69fe58089a02cf8dcc35842d</id>
<content type='text'>
commit e1e8a9624f7ba8ead4f056ff558ed070e86fa747 upstream.

User controlled KVM guests do not support the dirty log, as they have
no single gmap that we can check for changes.

As they have no single gmap, kvm-&gt;arch.gmap is NULL and all further
referencing to it for dirty checking will result in a NULL
dereference.

Let's return -EINVAL if a caller tries to sync dirty logs for a
UCONTROL guest.

Fixes: 15f36eb ("KVM: s390: Add proper dirty bitmap support to S390 kvm.")
Signed-off-by: Janosch Frank &lt;frankja@linux.vnet.ibm.com&gt;
Reported-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Reviewed-by: Cornelia Huck &lt;cornelia.huck@de.ibm.com&gt;
Signed-off-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
