<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/arch/s390, branch v5.12</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>s390/entry: save the caller of psw_idle</title>
<updated>2021-04-12T10:44:31+00:00</updated>
<author>
<name>Vasily Gorbik</name>
<email>gor@linux.ibm.com</email>
</author>
<published>2021-04-08T22:15:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=a994eddb947ea9ebb7b14d9a1267001699f0a136'/>
<id>a994eddb947ea9ebb7b14d9a1267001699f0a136</id>
<content type='text'>
Currently psw_idle does not allocate a stack frame and does not
save its r14 and r15 into the save area. Even though this is valid from
call ABI point of view, because psw_idle does not make any calls
explicitly, in reality psw_idle is an entry point for controlled
transition into serving interrupts. So, in practice, psw_idle stack
frame is analyzed during stack unwinding. Depending on build options
that r14 slot in the save area of psw_idle might either contain a value
saved by previous sibling call or complete garbage.

  [task    0000038000003c28] do_ext_irq+0xd6/0x160
  [task    0000038000003c78] ext_int_handler+0xba/0xe8
  [task   *0000038000003dd8] psw_idle_exit+0x0/0x8 &lt;-- pt_regs
 ([task    0000038000003dd8] 0x0)
  [task    0000038000003e10] default_idle_call+0x42/0x148
  [task    0000038000003e30] do_idle+0xce/0x160
  [task    0000038000003e70] cpu_startup_entry+0x36/0x40
  [task    0000038000003ea0] arch_call_rest_init+0x76/0x80

So, to make a stacktrace nicer and actually point for the real caller of
psw_idle in this frequently occurring case, make psw_idle save its r14.

  [task    0000038000003c28] do_ext_irq+0xd6/0x160
  [task    0000038000003c78] ext_int_handler+0xba/0xe8
  [task   *0000038000003dd8] psw_idle_exit+0x0/0x6 &lt;-- pt_regs
 ([task    0000038000003dd8] arch_cpu_idle+0x3c/0xd0)
  [task    0000038000003e10] default_idle_call+0x42/0x148
  [task    0000038000003e30] do_idle+0xce/0x160
  [task    0000038000003e70] cpu_startup_entry+0x36/0x40
  [task    0000038000003ea0] arch_call_rest_init+0x76/0x80

Reviewed-by: Sven Schnelle &lt;svens@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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently psw_idle does not allocate a stack frame and does not
save its r14 and r15 into the save area. Even though this is valid from
call ABI point of view, because psw_idle does not make any calls
explicitly, in reality psw_idle is an entry point for controlled
transition into serving interrupts. So, in practice, psw_idle stack
frame is analyzed during stack unwinding. Depending on build options
that r14 slot in the save area of psw_idle might either contain a value
saved by previous sibling call or complete garbage.

  [task    0000038000003c28] do_ext_irq+0xd6/0x160
  [task    0000038000003c78] ext_int_handler+0xba/0xe8
  [task   *0000038000003dd8] psw_idle_exit+0x0/0x8 &lt;-- pt_regs
 ([task    0000038000003dd8] 0x0)
  [task    0000038000003e10] default_idle_call+0x42/0x148
  [task    0000038000003e30] do_idle+0xce/0x160
  [task    0000038000003e70] cpu_startup_entry+0x36/0x40
  [task    0000038000003ea0] arch_call_rest_init+0x76/0x80

So, to make a stacktrace nicer and actually point for the real caller of
psw_idle in this frequently occurring case, make psw_idle save its r14.

  [task    0000038000003c28] do_ext_irq+0xd6/0x160
  [task    0000038000003c78] ext_int_handler+0xba/0xe8
  [task   *0000038000003dd8] psw_idle_exit+0x0/0x6 &lt;-- pt_regs
 ([task    0000038000003dd8] arch_cpu_idle+0x3c/0xd0)
  [task    0000038000003e10] default_idle_call+0x42/0x148
  [task    0000038000003e30] do_idle+0xce/0x160
  [task    0000038000003e70] cpu_startup_entry+0x36/0x40
  [task    0000038000003ea0] arch_call_rest_init+0x76/0x80

Reviewed-by: Sven Schnelle &lt;svens@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;
</pre>
</div>
</content>
</entry>
<entry>
<title>s390/entry: avoid setting up backchain in ext|io handlers</title>
<updated>2021-04-12T10:44:30+00:00</updated>
<author>
<name>Vasily Gorbik</name>
<email>gor@linux.ibm.com</email>
</author>
<published>2021-04-08T22:13:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b74e409ea1b18128b877a50883d92a12eba83c33'/>
<id>b74e409ea1b18128b877a50883d92a12eba83c33</id>
<content type='text'>
Currently when interrupt arrives to cpu while in kernel context
INT_HANDLER macro (used for ext_int_handler and io_int_handler)
allocates new stack frame and pt_regs on the kernel stack and
sets up the backchain to jump over the pt_regs to the frame which has
been interrupted. This is not ideal to two reasons:

1. This hides the fact that kernel stack contains interrupt frame in it
   and hence breaks arch_stack_walk_reliable(), which needs to know that to
   guarantee "reliability" and checks that there are no pt_regs on the way.

2. It breaks the backchain unwinder logic, which assumes that the next
   stack frame after an interrupt frame is reliable, while it is not.
   In some cases (when r14 contains garbage) this leads to early unwinding
   termination with an error, instead of marking frame as unreliable
   and continuing.

To address that, only set backchain to 0.

Fixes: 56e62a737028 ("s390: convert to generic entry")
Reviewed-by: Sven Schnelle &lt;svens@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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently when interrupt arrives to cpu while in kernel context
INT_HANDLER macro (used for ext_int_handler and io_int_handler)
allocates new stack frame and pt_regs on the kernel stack and
sets up the backchain to jump over the pt_regs to the frame which has
been interrupted. This is not ideal to two reasons:

1. This hides the fact that kernel stack contains interrupt frame in it
   and hence breaks arch_stack_walk_reliable(), which needs to know that to
   guarantee "reliability" and checks that there are no pt_regs on the way.

2. It breaks the backchain unwinder logic, which assumes that the next
   stack frame after an interrupt frame is reliable, while it is not.
   In some cases (when r14 contains garbage) this leads to early unwinding
   termination with an error, instead of marking frame as unreliable
   and continuing.

To address that, only set backchain to 0.

Fixes: 56e62a737028 ("s390: convert to generic entry")
Reviewed-by: Sven Schnelle &lt;svens@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;
</pre>
</div>
</content>
</entry>
<entry>
<title>s390/setup: use memblock_free_late() to free old stack</title>
<updated>2021-04-07T12:37:28+00:00</updated>
<author>
<name>Heiko Carstens</name>
<email>hca@linux.ibm.com</email>
</author>
<published>2021-04-05T20:32:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=ad31a8c05196a3dc5283b193e9c74a72022d3c65'/>
<id>ad31a8c05196a3dc5283b193e9c74a72022d3c65</id>
<content type='text'>
Use memblock_free_late() to free the old machine check stack to the
buddy allocator instead of leaking it.

Fixes: b61b1595124a ("s390: add stack for machine check handler")
Cc: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Acked-by: Sven Schnelle &lt;svens@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Use memblock_free_late() to free the old machine check stack to the
buddy allocator instead of leaking it.

Fixes: b61b1595124a ("s390: add stack for machine check handler")
Cc: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Acked-by: Sven Schnelle &lt;svens@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>s390/irq: fix reading of ext_params2 field from lowcore</title>
<updated>2021-04-05T09:30:07+00:00</updated>
<author>
<name>Heiko Carstens</name>
<email>hca@linux.ibm.com</email>
</author>
<published>2021-04-03T10:15:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=85012e764d3a1be02297b23c1aa3467f0df212aa'/>
<id>85012e764d3a1be02297b23c1aa3467f0df212aa</id>
<content type='text'>
The contents of the ext_params2 field of the lowcore should just be
copied to the pt_regs structure, not dereferenced.

Fixes crashes / program check loops like this:

Krnl PSW : 0404c00180000000 00000000d6d02b3c (do_ext_irq+0x74/0x170)
           R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3
Krnl GPRS: 0000000000000000 80000000000b974e 00000000d71abee0 00000000d71abee0
           0000000080030000 000000000000000f 0000000000000000 0000000000000000
           0000000000000001 00000380000bf918 00000000d73ef780 00000380000bf518
           0000000080348000 00000000d6d13350 00000000d6d02b1e 00000380000bf428
Krnl Code: 00000000d6d02b2e: 58100080            l       %r1,128
           00000000d6d02b32: 5010b0a4            st      %r1,164(%r11)
          #00000000d6d02b36: e31001b80104        lg      %r1,4536
          &gt;00000000d6d02b3c: e31010000004        lg      %r1,0(%r1)
           00000000d6d02b42: e310b0a80024        stg     %r1,168(%r11)
           00000000d6d02b48: c01000242270        larl    %r1,00000000d7187028
           00000000d6d02b4e: d5071000b010        clc     0(8,%r1),16(%r11)
           00000000d6d02b54: a784001b            brc     8,00000000d6d02b8a
Call Trace:
 [&lt;00000000d6d02b3c&gt;] do_ext_irq+0x74/0x170
 [&lt;00000000d6d0ea5c&gt;] ext_int_handler+0xc4/0xf4
 [&lt;00000000d621d266&gt;] die+0x106/0x188
 [&lt;00000000d62305b8&gt;] do_no_context+0xc8/0x100
 [&lt;00000000d6d02790&gt;] __do_pgm_check+0xe0/0x1f0
 [&lt;00000000d6d0e950&gt;] pgm_check_handler+0x118/0x160
 [&lt;00000000d6d02b3c&gt;] do_ext_irq+0x74/0x170
 [&lt;00000000d6d0ea5c&gt;] ext_int_handler+0xc4/0xf4
 [&lt;00000000d621d266&gt;] die+0x106/0x188
 [&lt;00000000d62305b8&gt;] do_no_context+0xc8/0x100
 [&lt;00000000d6d02790&gt;] __do_pgm_check+0xe0/0x1f0
 [&lt;00000000d6d0e950&gt;] pgm_check_handler+0x118/0x160
 [&lt;00000000d6d02b3c&gt;] do_ext_irq+0x74/0x170
 [&lt;00000000d6d0ea5c&gt;] ext_int_handler+0xc4/0xf4
 [&lt;0000000000000000&gt;] 0x0
 [&lt;00000000d6d0e57a&gt;] default_idle_call+0x42/0x110
 [&lt;00000000d629856e&gt;] do_idle+0xce/0x160
 [&lt;00000000d62987be&gt;] cpu_startup_entry+0x36/0x40
 [&lt;00000000d621f2f2&gt;] smp_start_secondary+0x82/0x88

Cc: Sven Schnelle &lt;svens@linux.ibm.com&gt;
Cc: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Fixes: 56e62a737028 ("s390: convert to generic entry")
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The contents of the ext_params2 field of the lowcore should just be
copied to the pt_regs structure, not dereferenced.

Fixes crashes / program check loops like this:

Krnl PSW : 0404c00180000000 00000000d6d02b3c (do_ext_irq+0x74/0x170)
           R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3
Krnl GPRS: 0000000000000000 80000000000b974e 00000000d71abee0 00000000d71abee0
           0000000080030000 000000000000000f 0000000000000000 0000000000000000
           0000000000000001 00000380000bf918 00000000d73ef780 00000380000bf518
           0000000080348000 00000000d6d13350 00000000d6d02b1e 00000380000bf428
Krnl Code: 00000000d6d02b2e: 58100080            l       %r1,128
           00000000d6d02b32: 5010b0a4            st      %r1,164(%r11)
          #00000000d6d02b36: e31001b80104        lg      %r1,4536
          &gt;00000000d6d02b3c: e31010000004        lg      %r1,0(%r1)
           00000000d6d02b42: e310b0a80024        stg     %r1,168(%r11)
           00000000d6d02b48: c01000242270        larl    %r1,00000000d7187028
           00000000d6d02b4e: d5071000b010        clc     0(8,%r1),16(%r11)
           00000000d6d02b54: a784001b            brc     8,00000000d6d02b8a
Call Trace:
 [&lt;00000000d6d02b3c&gt;] do_ext_irq+0x74/0x170
 [&lt;00000000d6d0ea5c&gt;] ext_int_handler+0xc4/0xf4
 [&lt;00000000d621d266&gt;] die+0x106/0x188
 [&lt;00000000d62305b8&gt;] do_no_context+0xc8/0x100
 [&lt;00000000d6d02790&gt;] __do_pgm_check+0xe0/0x1f0
 [&lt;00000000d6d0e950&gt;] pgm_check_handler+0x118/0x160
 [&lt;00000000d6d02b3c&gt;] do_ext_irq+0x74/0x170
 [&lt;00000000d6d0ea5c&gt;] ext_int_handler+0xc4/0xf4
 [&lt;00000000d621d266&gt;] die+0x106/0x188
 [&lt;00000000d62305b8&gt;] do_no_context+0xc8/0x100
 [&lt;00000000d6d02790&gt;] __do_pgm_check+0xe0/0x1f0
 [&lt;00000000d6d0e950&gt;] pgm_check_handler+0x118/0x160
 [&lt;00000000d6d02b3c&gt;] do_ext_irq+0x74/0x170
 [&lt;00000000d6d0ea5c&gt;] ext_int_handler+0xc4/0xf4
 [&lt;0000000000000000&gt;] 0x0
 [&lt;00000000d6d0e57a&gt;] default_idle_call+0x42/0x110
 [&lt;00000000d629856e&gt;] do_idle+0xce/0x160
 [&lt;00000000d62987be&gt;] cpu_startup_entry+0x36/0x40
 [&lt;00000000d621f2f2&gt;] smp_start_secondary+0x82/0x88

Cc: Sven Schnelle &lt;svens@linux.ibm.com&gt;
Cc: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Fixes: 56e62a737028 ("s390: convert to generic entry")
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>s390/unwind: add machine check handler stack</title>
<updated>2021-04-05T09:30:07+00:00</updated>
<author>
<name>Vasily Gorbik</name>
<email>gor@linux.ibm.com</email>
</author>
<published>2021-03-31T09:44:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=08edb9683e47f5183aed9aa3f926292b54c278c1'/>
<id>08edb9683e47f5183aed9aa3f926292b54c278c1</id>
<content type='text'>
Fixes: b61b1595124a ("s390: add stack for machine check handler")
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fixes: b61b1595124a ("s390: add stack for machine check handler")
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>s390/cpcmd: fix inline assembly register clobbering</title>
<updated>2021-04-05T09:30:07+00:00</updated>
<author>
<name>Alexander Gordeev</name>
<email>agordeev@linux.ibm.com</email>
</author>
<published>2021-03-29T16:35:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=7a2f91441b2c1d81b77c1cd816a4659f4abc9cbe'/>
<id>7a2f91441b2c1d81b77c1cd816a4659f4abc9cbe</id>
<content type='text'>
Register variables initialized using arithmetic. That leads to
kasan instrumentaton code corrupting the registers contents.
Follow GCC guidlines and use temporary variables for assigning
init values to register variables.

Fixes: 94c12cc7d196 ("[S390] Inline assembly cleanup.")
Signed-off-by: Alexander Gordeev &lt;agordeev@linux.ibm.com&gt;
Acked-by: Ilya Leoshkevich &lt;iii@linux.ibm.com&gt;
Link: https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Local-Register-Variables.html
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Register variables initialized using arithmetic. That leads to
kasan instrumentaton code corrupting the registers contents.
Follow GCC guidlines and use temporary variables for assigning
init values to register variables.

Fixes: 94c12cc7d196 ("[S390] Inline assembly cleanup.")
Signed-off-by: Alexander Gordeev &lt;agordeev@linux.ibm.com&gt;
Acked-by: Ilya Leoshkevich &lt;iii@linux.ibm.com&gt;
Link: https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Local-Register-Variables.html
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>s390/vdso: fix initializing and updating of vdso_data</title>
<updated>2021-03-25T20:57:26+00:00</updated>
<author>
<name>Heiko Carstens</name>
<email>hca@linux.ibm.com</email>
</author>
<published>2021-03-24T19:23:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=5b43bd184530af6b868d8273b0a743a138d37ee8'/>
<id>5b43bd184530af6b868d8273b0a743a138d37ee8</id>
<content type='text'>
Li Wang reported that clock_gettime(CLOCK_MONOTONIC_RAW, ...) returns
incorrect values when time is provided via vdso instead of system call:

vdso_ts_nsec = 4484351380985507, vdso_ts.tv_sec = 4484351, vdso_ts.tv_nsec = 380985507
sys_ts_nsec  = 1446923235377, sys_ts.tv_sec  = 1446, sys_ts.tv_nsec  = 923235377

Within the s390 specific vdso function __arch_get_hw_counter() reads
tod clock steering values from the arch_data member of the passed in
vdso_data structure.

Problem is that only for the CS_HRES_COARSE vdso_data arch_data is
initialized and gets updated. The CS_RAW specific vdso_data does not
contain any valid tod_clock_steering information, which explains the
different values.

Fix this by initializing and updating all vdso_datas.

Reported-by: Li Wang &lt;liwang@redhat.com&gt;
Tested-by: Li Wang &lt;liwang@redhat.com&gt;
Fixes: 1ba2d6c0fd4e ("s390/vdso: simplify __arch_get_hw_counter()")
Link: https://lore.kernel.org/linux-s390/YFnxr1ZlMIOIqjfq@osiris
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Li Wang reported that clock_gettime(CLOCK_MONOTONIC_RAW, ...) returns
incorrect values when time is provided via vdso instead of system call:

vdso_ts_nsec = 4484351380985507, vdso_ts.tv_sec = 4484351, vdso_ts.tv_nsec = 380985507
sys_ts_nsec  = 1446923235377, sys_ts.tv_sec  = 1446, sys_ts.tv_nsec  = 923235377

Within the s390 specific vdso function __arch_get_hw_counter() reads
tod clock steering values from the arch_data member of the passed in
vdso_data structure.

Problem is that only for the CS_HRES_COARSE vdso_data arch_data is
initialized and gets updated. The CS_RAW specific vdso_data does not
contain any valid tod_clock_steering information, which explains the
different values.

Fix this by initializing and updating all vdso_datas.

Reported-by: Li Wang &lt;liwang@redhat.com&gt;
Tested-by: Li Wang &lt;liwang@redhat.com&gt;
Fixes: 1ba2d6c0fd4e ("s390/vdso: simplify __arch_get_hw_counter()")
Link: https://lore.kernel.org/linux-s390/YFnxr1ZlMIOIqjfq@osiris
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>s390/vdso: fix tod_steering_delta type</title>
<updated>2021-03-25T20:57:25+00:00</updated>
<author>
<name>Heiko Carstens</name>
<email>hca@linux.ibm.com</email>
</author>
<published>2021-03-24T19:22:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b24bacd67ffddd9192c4745500fd6f73dbfe565e'/>
<id>b24bacd67ffddd9192c4745500fd6f73dbfe565e</id>
<content type='text'>
The s390 specific vdso function __arch_get_hw_counter() is supposed to
consider tod clock steering.

If a tod clock steering event happens and the tod clock is set to a
new value __arch_get_hw_counter() will not return the real tod clock
value but slowly drift it from the old delta until the returned value
finally matches the real tod clock value again.

Unfortunately the type of tod_steering_delta unsigned while it is
supposed to be signed. It depends on if tod_steering_delta is negative
or positive in which direction the vdso code drifts the clock value.

Worst case is now that instead of drifting the clock slowly it will
jump into the opposite direction by a factor of two.

Fix this by simply making tod_steering_delta signed.

Fixes: 4bff8cb54502 ("s390: convert to GENERIC_VDSO")
Cc: &lt;stable@vger.kernel.org&gt; # 5.10
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The s390 specific vdso function __arch_get_hw_counter() is supposed to
consider tod clock steering.

If a tod clock steering event happens and the tod clock is set to a
new value __arch_get_hw_counter() will not return the real tod clock
value but slowly drift it from the old delta until the returned value
finally matches the real tod clock value again.

Unfortunately the type of tod_steering_delta unsigned while it is
supposed to be signed. It depends on if tod_steering_delta is negative
or positive in which direction the vdso code drifts the clock value.

Worst case is now that instead of drifting the clock slowly it will
jump into the opposite direction by a factor of two.

Fix this by simply making tod_steering_delta signed.

Fixes: 4bff8cb54502 ("s390: convert to GENERIC_VDSO")
Cc: &lt;stable@vger.kernel.org&gt; # 5.10
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>s390/vdso: copy tod_steering_delta value to vdso_data page</title>
<updated>2021-03-25T20:57:25+00:00</updated>
<author>
<name>Heiko Carstens</name>
<email>hca@linux.ibm.com</email>
</author>
<published>2021-03-23T20:40:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=72bbc226ed2ef0a46c165a482861fff00dd6d4e1'/>
<id>72bbc226ed2ef0a46c165a482861fff00dd6d4e1</id>
<content type='text'>
When converting the vdso assembler code to C it was forgotten to
actually copy the tod_steering_delta value to vdso_data page.

Which in turn means that tod clock steering will not work correctly.

Fix this by simply copying the value whenever it is updated.

Fixes: 4bff8cb54502 ("s390: convert to GENERIC_VDSO")
Cc: &lt;stable@vger.kernel.org&gt; # 5.10
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When converting the vdso assembler code to C it was forgotten to
actually copy the tod_steering_delta value to vdso_data page.

Which in turn means that tod clock steering will not work correctly.

Fix this by simply copying the value whenever it is updated.

Fixes: 4bff8cb54502 ("s390: convert to GENERIC_VDSO")
Cc: &lt;stable@vger.kernel.org&gt; # 5.10
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>s390/pci: fix leak of PCI device structure</title>
<updated>2021-03-15T18:10:56+00:00</updated>
<author>
<name>Niklas Schnelle</name>
<email>schnelle@linux.ibm.com</email>
</author>
<published>2021-03-10T12:46:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=0b13525c20febcfecccf6fc1db5969727401317d'/>
<id>0b13525c20febcfecccf6fc1db5969727401317d</id>
<content type='text'>
In commit 05bc1be6db4b2 ("s390/pci: create zPCI bus") we removed the
pci_dev_put() call matching the earlier pci_get_slot() done as part of
__zpci_event_availability(). This was based on the wrong understanding
that the device_put() done as part of pci_destroy_device() would counter
the pci_get_slot() when it only counters the initial reference. This
same understanding and existing bad example also lead to not doing
a pci_dev_put() in zpci_remove_device().

Since releasing the PCI devices, unlike releasing the PCI slot, does not
print any debug message for testing I added one in pci_release_dev().
This revealed that we are indeed leaking the PCI device on PCI
hotunplug. Further testing also revealed another missing pci_dev_put() in
disable_slot().

Fix this by adding the missing pci_dev_put() in disable_slot() and fix
zpci_remove_device() with the correct pci_dev_put() calls. Also instead
of calling pci_get_slot() in __zpci_event_availability() to determine if
a PCI device is registered and then doing the same again in
zpci_remove_device() do this once in zpci_remove_device() which makes
sure that the pdev in __zpci_event_availability() is only used for the
result of pci_scan_single_device() which does not need a reference count
decremnt as its ownership goes to the PCI bus.

Also move the check if zdev-&gt;zbus-&gt;bus is set into zpci_remove_device()
since it may be that we're removing a device with devfn != 0 which never
had a PCI bus. So we can still set the pdev-&gt;error_state to indicate
that the device is not usable anymore, add a flag to set the error state.

Fixes: 05bc1be6db4b2 ("s390/pci: create zPCI bus")
Cc: &lt;stable@vger.kernel.org&gt; # 5.8+: e1bff843cde6 s390/pci: remove superfluous zdev-&gt;zbus check
Cc: &lt;stable@vger.kernel.org&gt; # 5.8+: ba764dd703fe s390/pci: refactor zpci_create_device()
Cc: &lt;stable@vger.kernel.org&gt; # 5.8+
Reviewed-by: Matthew Rosato &lt;mjrosato@linux.ibm.com&gt;
Signed-off-by: Niklas Schnelle &lt;schnelle@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In commit 05bc1be6db4b2 ("s390/pci: create zPCI bus") we removed the
pci_dev_put() call matching the earlier pci_get_slot() done as part of
__zpci_event_availability(). This was based on the wrong understanding
that the device_put() done as part of pci_destroy_device() would counter
the pci_get_slot() when it only counters the initial reference. This
same understanding and existing bad example also lead to not doing
a pci_dev_put() in zpci_remove_device().

Since releasing the PCI devices, unlike releasing the PCI slot, does not
print any debug message for testing I added one in pci_release_dev().
This revealed that we are indeed leaking the PCI device on PCI
hotunplug. Further testing also revealed another missing pci_dev_put() in
disable_slot().

Fix this by adding the missing pci_dev_put() in disable_slot() and fix
zpci_remove_device() with the correct pci_dev_put() calls. Also instead
of calling pci_get_slot() in __zpci_event_availability() to determine if
a PCI device is registered and then doing the same again in
zpci_remove_device() do this once in zpci_remove_device() which makes
sure that the pdev in __zpci_event_availability() is only used for the
result of pci_scan_single_device() which does not need a reference count
decremnt as its ownership goes to the PCI bus.

Also move the check if zdev-&gt;zbus-&gt;bus is set into zpci_remove_device()
since it may be that we're removing a device with devfn != 0 which never
had a PCI bus. So we can still set the pdev-&gt;error_state to indicate
that the device is not usable anymore, add a flag to set the error state.

Fixes: 05bc1be6db4b2 ("s390/pci: create zPCI bus")
Cc: &lt;stable@vger.kernel.org&gt; # 5.8+: e1bff843cde6 s390/pci: remove superfluous zdev-&gt;zbus check
Cc: &lt;stable@vger.kernel.org&gt; # 5.8+: ba764dd703fe s390/pci: refactor zpci_create_device()
Cc: &lt;stable@vger.kernel.org&gt; # 5.8+
Reviewed-by: Matthew Rosato &lt;mjrosato@linux.ibm.com&gt;
Signed-off-by: Niklas Schnelle &lt;schnelle@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
