Re: [ANNOUNCE] v5.4.17-rt9

[Fernando Lopez-Lezcano]

On 2/4/20 8:58 AM, Sebastian Andrzej Siewior wrote:
> Dear RT folks!
>
> I'm pleased to announce the v5.4.17-rt9 patch set.

Thanks!
I see a continuous stream of these:

----
[165992.032318] BUG: sleeping function called from invalid context at 
kernel/locking/rtmutex.c:973
[165992.032320] in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 
12209, name: kworker/u8:3
[165992.032322] INFO: lockdep is turned off.
[165992.032322] irq event stamp: 0
[165992.032323] hardirqs last  enabled at (0): [<0000000000000000>] 0x0
[165992.032325] hardirqs last disabled at (0): [<ffffffff980ed372>] 
copy_process+0x802/0x2000
[165992.032329] softirqs last  enabled at (0): [<ffffffff980ed372>] 
copy_process+0x802/0x2000
[165992.032331] softirqs last disabled at (0): [<0000000000000000>] 0x0
[165992.032332] CPU: 2 PID: 12209 Comm: kworker/u8:3 Tainted: G        W 
        5.4.17-100.rt9.1.fc30.ccrma.x86_64+rt #1
[165992.032333] Hardware name:  /NUC6i7KYB, BIOS 
KYSKLi70.86A.0034.2016.0503.1003 05/03/2016
[165992.032369] Workqueue: i915 retire_work_handler [i915]
[165992.032369] Call Trace:
[165992.032373]  dump_stack+0x8f/0xd0
[165992.032377]  ___might_sleep.cold+0xb3/0xc3
[165992.032380]  rt_spin_lock_nested+0x8e/0xd0
[165992.032382]  ? __i915_sw_fence_complete+0x15c/0x200 [i915]
[165992.032407]  __i915_sw_fence_complete+0x15c/0x200 [i915]
[165992.032432]  __i915_request_queue+0x19/0x50 [i915]
[165992.032463]  __engine_park+0xe2/0x1d0 [i915]
[165992.032489]  ____intel_wakeref_put_last+0x1e/0x50 [i915]
[165992.032511]  i915_request_retire+0x293/0x480 [i915]
[165992.032541]  retire_requests+0x54/0x60 [i915]
[165992.032569]  i915_retire_requests+0xea/0x220 [i915]
[165992.032598]  retire_work_handler+0x56/0x60 [i915]
[165992.032626]  process_one_work+0x261/0x6c0
[165992.032631]  worker_thread+0x50/0x3b0
[165992.032634]  kthread+0x106/0x140
[165992.032636]  ? process_one_work+0x6c0/0x6c0
[165992.032638]  ? kthread_park+0x90/0x90
[165992.032640]  ret_from_fork+0x3a/0x50
----

Something similar used to happen a while back, but I had not seen it on 
5.2.x rt patched kernels. It is back (or something very similar).

This is on Fedora 30 upgraded to the latest, and the kernel is based on 
(as I normally do) the source package for the equivalent Fedora kernel, 
with the RT patch added (and configured).

Thanks again for your work!
-- Fernando


> Changes since v5.4.17-rt8:
>
>    - A rework of percpu-rwsem locking. The fs core was using a
>      percpu-rwsem and returned with acquired lock to userland during
>      `fsfreeze' which led warnings. On !RT the warnings were disabled but
>      the same lockdep trick did not work on RT.
>      Reported by Juri Lelli, patch(es) by Peter Zijlstra.
>
>    - Include a header file the `current' macro to not break an allmod
>      build on ARM.
>
>    - A tweak to migrate_enable() to not having to wait until
>      stop_one_cpu_nowait() finishes in case CPU-mask changed during
>      migrate_disable() and the CPU has to be changed. Patch by Scott
>      Wood.
>
>    - Drop a lock earlier in mm/memcontrol. Not a bug but there is no need
>      for the additional locked section. Patch by Matt Fleming.
>
> Known issues
>       - None