<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/s390/kernel, branch linux-5.9.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.9.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.9.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2020-12-16T09:58:34Z</updated>
<entry>
<title>s390: fix irq state tracing</title>
<updated>2020-12-16T09:58:34Z</updated>
<author>
<name>Heiko Carstens</name>
</author>
<published>2020-12-02T10:46:01Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d00ee4dc1cd9dba5c5f9b67bb00c1d5c98b791ad'/>
<id>urn:sha1:d00ee4dc1cd9dba5c5f9b67bb00c1d5c98b791ad</id>
<content type='text'>
[ Upstream commit b1cae1f84a0f609a34ebcaa087fbecef32f69882 ]

With commit 58c644ba512c ("sched/idle: Fix arch_cpu_idle() vs
tracing") common code calls arch_cpu_idle() with a lockdep state that
tells irqs are on.

This doesn't work very well for s390: psw_idle() will enable interrupts
to wait for an interrupt. As soon as an interrupt occurs the interrupt
handler will verify if the old context was psw_idle(). If that is the
case the interrupt enablement bits in the old program status word will
be cleared.

A subsequent test in both the external as well as the io interrupt
handler checks if in the old context interrupts were enabled. Due to
the above patching of the old program status word it is assumed the
old context had interrupts disabled, and therefore a call to
TRACE_IRQS_OFF (aka trace_hardirqs_off_caller) is skipped. Which in
turn makes lockdep incorrectly "think" that interrupts are enabled
within the interrupt handler.

Fix this by unconditionally calling TRACE_IRQS_OFF when entering
interrupt handlers. Also call unconditionally TRACE_IRQS_ON when
leaving interrupts handlers.

This leaves the special psw_idle() case, which now returns with
interrupts disabled, but has an "irqs on" lockdep state. So callers of
psw_idle() must adjust the state on their own, if required. This is
currently only __udelay_disabled().

Fixes: 58c644ba512c ("sched/idle: Fix arch_cpu_idle() vs tracing")
Acked-by: Peter Zijlstra (Intel) &lt;peterz@infradead.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>sched/idle: Fix arch_cpu_idle() vs tracing</title>
<updated>2020-12-16T09:58:32Z</updated>
<author>
<name>Peter Zijlstra</name>
</author>
<published>2020-11-20T10:50:35Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=fb82d3ac7ec1ffb5f4758b025bfdcd1b82eeddd5'/>
<id>urn:sha1:fb82d3ac7ec1ffb5f4758b025bfdcd1b82eeddd5</id>
<content type='text'>
[ Upstream commit 58c644ba512cfbc2e39b758dd979edd1d6d00e27 ]

We call arch_cpu_idle() with RCU disabled, but then use
local_irq_{en,dis}able(), which invokes tracing, which relies on RCU.

Switch all arch_cpu_idle() implementations to use
raw_local_irq_{en,dis}able() and carefully manage the
lockdep,rcu,tracing state like we do in entry.

(XXX: we really should change arch_cpu_idle() to not return with
interrupts enabled)

Reported-by: Sven Schnelle &lt;svens@linux.ibm.com&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Reviewed-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Tested-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Link: https://lkml.kernel.org/r/20201120114925.594122626@infradead.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>s390: fix fpu restore in entry.S</title>
<updated>2020-12-02T07:51:44Z</updated>
<author>
<name>Sven Schnelle</name>
</author>
<published>2020-11-20T13:17:52Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ec5c0fc8b0ad27d5b8f1b44b301b2ec9589748a8'/>
<id>urn:sha1:ec5c0fc8b0ad27d5b8f1b44b301b2ec9589748a8</id>
<content type='text'>
commit 1179f170b6f0af7bb0b3b7628136eaac450ddf31 upstream.

We need to disable interrupts in load_fpu_regs(). Otherwise an
interrupt might come in after the registers are loaded, but before
CIF_FPU is cleared in load_fpu_regs(). When the interrupt returns,
CIF_FPU will be cleared and the registers will never be restored.

The entry.S code usually saves the interrupt state in __SF_EMPTY on the
stack when disabling/restoring interrupts. sie64a however saves the pointer
to the sie control block in __SF_SIE_CONTROL, which references the same
location.  This is non-obvious to the reader. To avoid thrashing the sie
control block pointer in load_fpu_regs(), move the __SIE_* offsets eight
bytes after __SF_EMPTY on the stack.

Cc: &lt;stable@vger.kernel.org&gt; # 5.8
Fixes: 0b0ed657fe00 ("s390: remove critical section cleanup from entry.S")
Reported-by: Pierre Morel &lt;pmorel@linux.ibm.com&gt;
Signed-off-by: Sven Schnelle &lt;svens@linux.ibm.com&gt;
Acked-by: Christian Borntraeger &lt;borntraeger@de.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/cpum_sf.c: fix file permission for cpum_sfb_size</title>
<updated>2020-11-24T12:39:12Z</updated>
<author>
<name>Thomas Richter</name>
</author>
<published>2020-11-11T15:26:25Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=382bb0bed97cbc161749df0fce4d06fd39c1046d'/>
<id>urn:sha1:382bb0bed97cbc161749df0fce4d06fd39c1046d</id>
<content type='text'>
commit 78d732e1f326f74f240d416af9484928303d9951 upstream.

This file is installed by the s390 CPU Measurement sampling
facility device driver to export supported minimum and
maximum sample buffer sizes.
This file is read by lscpumf tool to display the details
of the device driver capabilities. The lscpumf tool might
be invoked by a non-root user. In this case it does not
print anything because the file contents can not be read.

Fix this by allowing read access for all users. Reading
the file contents is ok, changing the file contents is
left to the root user only.

For further reference and details see:
 [1] https://github.com/ibm-s390-tools/s390-tools/issues/97

Fixes: 69f239ed335a ("s390/cpum_sf: Dynamically extend the sampling buffer if overflows occur")
Cc: &lt;stable@vger.kernel.org&gt; # 3.14
Signed-off-by: Thomas Richter &lt;tmricht@linux.ibm.com&gt;
Acked-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: fix system call exit path</title>
<updated>2020-11-24T12:39:12Z</updated>
<author>
<name>Heiko Carstens</name>
</author>
<published>2020-11-03T15:55:43Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d21f8e25cabfa7e37d91c7eceb89f915d1556d4e'/>
<id>urn:sha1:d21f8e25cabfa7e37d91c7eceb89f915d1556d4e</id>
<content type='text'>
commit ce9dfafe29bed86fe3cda330ac6072ce84e1ff81 upstream.

The system call exit path is running with interrupts enabled while
checking for TIF/PIF/CIF bits which require special handling. If all
bits have been checked interrupts are disabled and the kernel exits to
user space.
The problem is that after checking all bits and before interrupts are
disabled bits can be set already again, due to interrupt handling.

This means that the kernel can exit to user space with some
TIF/PIF/CIF bits set, which should never happen. E.g. TIF_NEED_RESCHED
might be set, which might lead to additional latencies, since that bit
will only be recognized with next exit to user space.

Fix this by checking the corresponding bits only when interrupts are
disabled.

Fixes: 0b0ed657fe00 ("s390: remove critical section cleanup from entry.S")
Cc: &lt;stable@vger.kernel.org&gt; # 5.8
Acked-by: Sven Schnelle &lt;svens@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/smp: move rcu_cpu_starting() earlier</title>
<updated>2020-11-18T18:22:13Z</updated>
<author>
<name>Qian Cai</name>
</author>
<published>2020-10-28T18:27:42Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e68d3689dcfa003b4808e124855ec872f5564fc4'/>
<id>urn:sha1:e68d3689dcfa003b4808e124855ec872f5564fc4</id>
<content type='text'>
[ Upstream commit de5d9dae150ca1c1b5c7676711a9ca139d1a8dec ]

The call to rcu_cpu_starting() in smp_init_secondary() is not early
enough in the CPU-hotplug onlining process, which results in lockdep
splats as follows:

 WARNING: suspicious RCU usage
 -----------------------------
 kernel/locking/lockdep.c:3497 RCU-list traversed in non-reader section!!

 other info that might help us debug this:

 RCU used illegally from offline CPU!
 rcu_scheduler_active = 1, debug_locks = 1
 no locks held by swapper/1/0.

 Call Trace:
 show_stack+0x158/0x1f0
 dump_stack+0x1f2/0x238
 __lock_acquire+0x2640/0x4dd0
 lock_acquire+0x3a8/0xd08
 _raw_spin_lock_irqsave+0xc0/0xf0
 clockevents_register_device+0xa8/0x528
 init_cpu_timer+0x33e/0x468
 smp_init_secondary+0x11a/0x328
 smp_start_secondary+0x82/0x88

This is avoided by moving the call to rcu_cpu_starting up near the
beginning of the smp_init_secondary() function. Note that the
raw_smp_processor_id() is required in order to avoid calling into
lockdep before RCU has declared the CPU to be watched for readers.

Link: https://lore.kernel.org/lkml/160223032121.7002.1269740091547117869.tip-bot2@tip-bot2/
Signed-off-by: Qian Cai &lt;cai@redhat.com&gt;
Acked-by: Paul E. McKenney &lt;paulmck@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>kbuild: explicitly specify the build id style</title>
<updated>2020-11-18T18:22:07Z</updated>
<author>
<name>Bill Wendling</name>
</author>
<published>2020-09-22T23:21:40Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6809b33291367c07ccaab29c4e366b762b832fe3'/>
<id>urn:sha1:6809b33291367c07ccaab29c4e366b762b832fe3</id>
<content type='text'>
[ Upstream commit a968433723310f35898b4a2f635a7991aeef66b1 ]

ld's --build-id defaults to "sha1" style, while lld defaults to "fast".
The build IDs are very different between the two, which may confuse
programs that reference them.

Signed-off-by: Bill Wendling &lt;morbo@google.com&gt;
Acked-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>s390/stp: add locking to sysfs functions</title>
<updated>2020-11-05T10:51:44Z</updated>
<author>
<name>Sven Schnelle</name>
</author>
<published>2020-09-15T06:53:50Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0c310c8bb3ea63dfe7bc3311160e5019a3876f69'/>
<id>urn:sha1:0c310c8bb3ea63dfe7bc3311160e5019a3876f69</id>
<content type='text'>
commit b3bd02495cb339124f13135d51940cf48d83e5cb upstream.

The sysfs function might race with stp_work_fn. To prevent that,
add the required locking. Another issue is that the sysfs functions
are checking the stp_online flag, but this flag just holds the user
setting whether STP is enabled. Add a flag to clock_sync_flag whether
stp_info holds valid data and use that instead.

Cc: stable@vger.kernel.org
Signed-off-by: Sven Schnelle &lt;svens@linux.ibm.com&gt;
Reviewed-by: Alexander Egorenkov &lt;egorenar@linux.ibm.com&gt;
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: add 3f program exception handler</title>
<updated>2020-09-14T08:08:07Z</updated>
<author>
<name>Janosch Frank</name>
</author>
<published>2020-09-08T13:05:04Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=cd4d3d5f21ddbfae3f686ac0ff405f21f7847ad3'/>
<id>urn:sha1:cd4d3d5f21ddbfae3f686ac0ff405f21f7847ad3</id>
<content type='text'>
Program exception 3f (secure storage violation) can only be detected
when the CPU is running in SIE with a format 4 state description,
e.g. running a protected guest. Because of this and because user
space partly controls the guest memory mapping and can trigger this
exception, we want to send a SIGSEGV to the process running the guest
and not panic the kernel.

Signed-off-by: Janosch Frank &lt;frankja@linux.ibm.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 5.7
Fixes: 084ea4d611a3 ("s390/mm: add (non)secure page access exceptions handlers")
Reviewed-by: Claudio Imbrenda &lt;imbrenda@linux.ibm.com&gt;
Reviewed-by: Cornelia Huck &lt;cohuck@redhat.com&gt;
Acked-by: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/init: add missing __init annotations</title>
<updated>2020-09-14T08:08:07Z</updated>
<author>
<name>Ilya Leoshkevich</name>
</author>
<published>2020-09-09T12:27:25Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=fcb2b70cdb194157678fb1a75f9ff499aeba3d2a'/>
<id>urn:sha1:fcb2b70cdb194157678fb1a75f9ff499aeba3d2a</id>
<content type='text'>
Add __init to reserve_memory_end, reserve_oldmem and remove_oldmem.
Sometimes these functions are not inlined, and then the build
complains about section mismatch.

Signed-off-by: Ilya Leoshkevich &lt;iii@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
</content>
</entry>
</feed>
