Linux v4.19.115-rt50-rc1

From: Tom Zanussi <[email protected]>

Dear RT Folks,

This is the RT stable review cycle of patch 4.19.115-rt50-rc1.

Please scream at me if I messed something up. Please test the patches too.

The -rc release will be uploaded to kernel.org and will be deleted when the final release is out. This is just a review release (or release candidate).

The pre-releases will not be pushed to the git repository, only the final release is.

If all goes well, this patch will be converted to the next main release on 2020-05-01.

To build 4.19.115-rt50-rc1 directly, the following patches should be applied:

https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.19.tar.xz

https://www.kernel.org/pub/linux/kernel/v4.x/patch-4.19.115.xz

https://www.kernel.org/pub/linux/kernel/projects/rt/4.19/patch-4.19.115-rt50-rc1.patch.xz

You can also build from 4.19.115-rt49 by applying the incremental patch:

https://www.kernel.org/pub/linux/kernel/projects/rt/4.19/incr/patch-4.19.115-rt49-rt50-rc1.patch.xz

Enjoy,

-- Tom

Rasmus Villemoes (1):
hrtimer: fix logic for when grabbing softirq_expiry_lock can be elided

Tom Zanussi (1):
Linux 4.19.115-rt50-rc1

 kernel/time/hrtimer.c | 2 +-
 localversion-rt       | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

2.17.1

From: Rasmus Villemoes <[email protected]>

v4.19.115-rt50-rc1 stable review patch.
If anyone has any objections, please let me know.

-----------

Commit

hrtimer: Add a missing bracket and hide `migration_base' on !SMP

which is 47b6de0b7f22 in 5.2-rt and 40aae5708e7a in 4.19-rt, inadvertently changed the logic from base != &migration_base to base == &migration_base.

On !CONFIG_SMP, the effect was to effectively always elide this lock/unlock pair (since is_migration_base() is unconditionally false), which for me consistently causes lockups during reboot, and reportedly also often causes a hang during boot.

Adding this logical negation (or, what is effectively the same thing on !CONFIG_SMP, reverting the above commit as well as "hrtimer:
Prevent using hrtimer_grab_expiry_lock() on migration_base") fixes that lockup.

---
 kernel/time/hrtimer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index e54a95de8b79..c3966c090246 100644
@@ -953,7 +953,7 @@ void hrtimer_grab_expiry_lock(const struct hrtimer *timer)
 {
 	struct hrtimer_clock_base *base = READ_ONCE(timer->base);
 
-	if (timer->is_soft && is_migration_base(base)) {
+	if (timer->is_soft && !is_migration_base(base)) {
 		spin_lock(&base->cpu_base->softirq_expiry_lock);
 		spin_unlock(&base->cpu_base->softirq_expiry_lock);
 	}

2.17.1

From: Tom Zanussi <[email protected]>

v4.19.115-rt50-rc1 stable review patch.
If anyone has any objections, please let me know.

-----------

---
 localversion-rt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 4b7dca68a5b4..e8a9a36bb066 100644
@@ -1 +1 @@
--rt49
+-rt50-rc1

2.17.1

For good measure, the customer reports that 4.19.115-rt50-rc1 indeed seems to fix the boot hang they saw.

Thanks,
Rasmus

OK, great, glad to hear that.

Thanks,

Tom