<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/s390/include, branch linux-3.10.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.10.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.10.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2017-06-20T12:04:26Z</updated>
<entry>
<title>s390: TASK_SIZE for kernel threads</title>
<updated>2017-06-20T12:04:26Z</updated>
<author>
<name>Martin Schwidefsky</name>
</author>
<published>2017-02-24T06:43:51Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=71116d6a8d98c68f7561af3c641dd0764b69d73a'/>
<id>urn:sha1:71116d6a8d98c68f7561af3c641dd0764b69d73a</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: Willy Tarreau &lt;w@1wt.eu&gt;
</content>
</entry>
<entry>
<title>KVM: s390: fix task size check</title>
<updated>2017-06-20T12:04:26Z</updated>
<author>
<name>Martin Schwidefsky</name>
</author>
<published>2013-07-26T13:04:03Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f7bbcabc5e963cc49e3e1b4e82f80117487868e7'/>
<id>urn:sha1:f7bbcabc5e963cc49e3e1b4e82f80117487868e7</id>
<content type='text'>
The gmap_map_segment function uses PGDIR_SIZE in the check for the
maximum address in the tasks address space. This incorrectly limits
the amount of memory usable for a kvm guest to 4TB. The correct limit
is (1UL &lt;&lt; 53). As the TASK_SIZE has different values (4TB vs 8PB)
dependent on the existance of the fourth page table level, create
a new define 'TASK_MAX_SIZE' for (1UL &lt;&lt; 53).

Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Signed-off-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
</content>
</entry>
<entry>
<title>s390: get_user() should zero on failure</title>
<updated>2017-02-06T22:32:59Z</updated>
<author>
<name>Al Viro</name>
</author>
<published>2016-08-22T02:00:54Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ed98892e36f323058ce203de3f4ea17b507e8b44'/>
<id>urn:sha1:ed98892e36f323058ce203de3f4ea17b507e8b44</id>
<content type='text'>
commit fd2d2b191fe75825c4c7a6f12f3fef35aaed7dd7 upstream.

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
</content>
</entry>
<entry>
<title>s390/seccomp: fix error return for filtered system calls</title>
<updated>2016-08-27T09:40:30Z</updated>
<author>
<name>Jan Willeke</name>
</author>
<published>2014-07-22T14:50:57Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=884c6beca31ef639a7002f461efbe036c22006de'/>
<id>urn:sha1:884c6beca31ef639a7002f461efbe036c22006de</id>
<content type='text'>
commit dc295880c6752076f8b94ba3885d0bfff09e3e82 upstream.

The syscall_set_return_value function of s390 negates the error argument
before storing the value to the return register gpr2. This is incorrect,
the seccomp code already passes the negative error value.
Store the unmodified error value to gpr2.

Signed-off-by: Jan Willeke &lt;willeke@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
</content>
</entry>
<entry>
<title>s390/lowcore: reserve 96 bytes for IRB in lowcore</title>
<updated>2014-07-01T03:09:42Z</updated>
<author>
<name>Christian Borntraeger</name>
</author>
<published>2014-05-26T19:55:08Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=07e6e46256b9168213f4aa8896618367876fd9d1'/>
<id>urn:sha1:07e6e46256b9168213f4aa8896618367876fd9d1</id>
<content type='text'>
commit 993072ee67aa179c48c85eb19869804e68887d86 upstream.

The IRB might be 96 bytes if the extended-I/O-measurement facility is
used. This feature is currently not used by Linux, but struct irb
already has the emw defined. So let's make the irb in lowcore match the
size of the internal data structure to be future proof.
We also have to add a pad, to correctly align the paste.

The bigger irb field also circumvents a bug in some QEMU versions that
always write the emw field on test subchannel and therefore destroy the
paste definitions of this CPU. Running under these QEMU version broke
some timing functions in the VDSO and all users of these functions,
e.g. some JREs.

Signed-off-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Cc: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Cc: Sebastian Ott &lt;sebott@linux.vnet.ibm.com&gt;
Cc: Cornelia Huck &lt;cornelia.huck@de.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>s390/cio: fix driver callback initialization for ccw consoles</title>
<updated>2014-05-06T14:55:27Z</updated>
<author>
<name>Sebastian Ott</name>
</author>
<published>2014-01-27T12:26:10Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6a52b43b32fc1886b2a6c62567742962a9188278'/>
<id>urn:sha1:6a52b43b32fc1886b2a6c62567742962a9188278</id>
<content type='text'>
commit 2253e8d79237c69086ded391e6767afe16972527 upstream.

ccw consoles are in use before they can be properly registered with
the driver core. For devices which are in use by a device driver we
rely on the ccw_device's pointer to the driver callbacks to be valid.
For ccw consoles this pointer is NULL until they are registered later
during boot and we dereferenced this pointer. This worked by
chance on 64 bit builds (cdev-&gt;drv was NULL but the optional callback
cdev-&gt;drv-&gt;path_event was also NULL by coincidence) and was unnoticed
until we received reports about boot failures on 31 bit systems.
Fix it by initializing the driver pointer for ccw consoles.

Reported-by: Mike Frysinger &lt;vapier@gentoo.org&gt;
Reported-by: Heiko Carstens &lt;heiko.carstens@de.ibm.com&gt;
Reviewed-by: Peter Oberparleiter &lt;oberpar@linux.vnet.ibm.com&gt;
Signed-off-by: Sebastian Ott &lt;sebott@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>s390/uapi: fix struct statfs64 definition</title>
<updated>2014-02-06T19:08:15Z</updated>
<author>
<name>Heiko Carstens</name>
</author>
<published>2014-01-21T16:31:10Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=cca90a970d9b18e56fb53dbcec448ba2b641170c'/>
<id>urn:sha1:cca90a970d9b18e56fb53dbcec448ba2b641170c</id>
<content type='text'>
commit 4e078146dff728f4865270a47710d57797e81eb6 upstream.

With b8668fd0a7e1b59f "s390/uapi: change struct statfs[64] member types
to unsigned values" the size of a couple of struct statfs64 member got
incorrectly changed from 64 to 32 bit for 32 bit builds.

Fix this by changing the type of couple of struct statfs64 members from
unsigned long to unsigned long long.
The definition of struct compat_statfs64 was correct however.

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>compiler/gcc4: Add quirk for 'asm goto' miscompilation bug</title>
<updated>2013-10-18T14:45:45Z</updated>
<author>
<name>Ingo Molnar</name>
</author>
<published>2013-10-10T08:16:30Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bb42ad4e4d2c1c10637368c750a5683100f2ddfa'/>
<id>urn:sha1:bb42ad4e4d2c1c10637368c750a5683100f2ddfa</id>
<content type='text'>
commit 3f0116c3238a96bc18ad4b4acefe4e7be32fa861 upstream.

Fengguang Wu, Oleg Nesterov and Peter Zijlstra tracked down
a kernel crash to a GCC bug: GCC miscompiles certain 'asm goto'
constructs, as outlined here:

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670

Implement a workaround suggested by Jakub Jelinek.

Reported-and-tested-by: Fengguang Wu &lt;fengguang.wu@intel.com&gt;
Reported-by: Oleg Nesterov &lt;oleg@redhat.com&gt;
Reported-by: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Suggested-by: Jakub Jelinek &lt;jakub@redhat.com&gt;
Reviewed-by: Richard Henderson &lt;rth@twiddle.net&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Link: http://lkml.kernel.org/r/20131015062351.GA4666@gmail.com
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>s390: Fix broken build</title>
<updated>2013-08-20T15:43:05Z</updated>
<author>
<name>Guenter Roeck</name>
</author>
<published>2013-08-17T03:50:55Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9234930d6e89a7671042e6e35e318480d6b82e5f'/>
<id>urn:sha1:9234930d6e89a7671042e6e35e318480d6b82e5f</id>
<content type='text'>
commit 215b28a5308f3d332df2ee09ef11fda45d7e4a92 upstream.

Fix this build error:

  In file included from fs/exec.c:61:0:
  arch/s390/include/asm/tlb.h:35:23: error: expected identifier or '(' before 'unsigned'
  arch/s390/include/asm/tlb.h:36:1: warning: no semicolon at end of struct or union [enabled by default]
  arch/s390/include/asm/tlb.h: In function 'tlb_gather_mmu':
  arch/s390/include/asm/tlb.h:57:5: error: 'struct mmu_gather' has no member named 'end'

Broken due to commit 2b047252d0 ("Fix TLB gather virtual address range
invalidation corner cases").

Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
[ Oh well. We had build testing for ppc amd um, but no s390  - Linus ]
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Fix TLB gather virtual address range invalidation corner cases</title>
<updated>2013-08-20T15:43:05Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2013-08-15T18:42:25Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8e220cfd1a9f6c763a108a3b964a888fe341dabd'/>
<id>urn:sha1:8e220cfd1a9f6c763a108a3b964a888fe341dabd</id>
<content type='text'>
commit 2b047252d087be7f2ba088b4933cd904f92e6fce upstream.

Ben Tebulin reported:

 "Since v3.7.2 on two independent machines a very specific Git
  repository fails in 9/10 cases on git-fsck due to an SHA1/memory
  failures.  This only occurs on a very specific repository and can be
  reproduced stably on two independent laptops.  Git mailing list ran
  out of ideas and for me this looks like some very exotic kernel issue"

and bisected the failure to the backport of commit 53a59fc67f97 ("mm:
limit mmu_gather batching to fix soft lockups on !CONFIG_PREEMPT").

That commit itself is not actually buggy, but what it does is to make it
much more likely to hit the partial TLB invalidation case, since it
introduces a new case in tlb_next_batch() that previously only ever
happened when running out of memory.

The real bug is that the TLB gather virtual memory range setup is subtly
buggered.  It was introduced in commit 597e1c3580b7 ("mm/mmu_gather:
enable tlb flush range in generic mmu_gather"), and the range handling
was already fixed at least once in commit e6c495a96ce0 ("mm: fix the TLB
range flushed when __tlb_remove_page() runs out of slots"), but that fix
was not complete.

The problem with the TLB gather virtual address range is that it isn't
set up by the initial tlb_gather_mmu() initialization (which didn't get
the TLB range information), but it is set up ad-hoc later by the
functions that actually flush the TLB.  And so any such case that forgot
to update the TLB range entries would potentially miss TLB invalidates.

Rather than try to figure out exactly which particular ad-hoc range
setup was missing (I personally suspect it's the hugetlb case in
zap_huge_pmd(), which didn't have the same logic as zap_pte_range()
did), this patch just gets rid of the problem at the source: make the
TLB range information available to tlb_gather_mmu(), and initialize it
when initializing all the other tlb gather fields.

This makes the patch larger, but conceptually much simpler.  And the end
result is much more understandable; even if you want to play games with
partial ranges when invalidating the TLB contents in chunks, now the
range information is always there, and anybody who doesn't want to
bother with it won't introduce subtle bugs.

Ben verified that this fixes his problem.

Reported-bisected-and-tested-by: Ben Tebulin &lt;tebulin@googlemail.com&gt;
Build-testing-by: Stephen Rothwell &lt;sfr@canb.auug.org.au&gt;
Build-testing-by: Richard Weinberger &lt;richard.weinberger@gmail.com&gt;
Reviewed-by: Michal Hocko &lt;mhocko@suse.cz&gt;
Acked-by: Peter Zijlstra &lt;peterz@infradead.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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