Stable backports

Stable backports

[Sebastian Andrzej Siewior]

Hi,

I've been looking over my queue and which patches vanishes (as in
applied somewhere) and did not show up in the stable tree. Here is a
list of some suggestions:

- 7eb16f23b9a41 ("io-mapping: don't disable preempt on RT in io_mapping_map_atomic_wc().")
- 286deb7ec03d9 ("locking/rwbase: Mitigate indefinite writer starvation")
- 1c0908d8e4416 ("rtmutex: Add acquire semantics for rtmutex lock acquisition slow path")
  (is in v6.1 but not in v5.15)
- b8a04a538ed47 ("revert: "softirq: Let ksoftirqd do its job"")
- 38cdd83a47fb2 ("tracing/timer: Add missing hrtimer modes to decode_hrtimer_mode().")

Sebastian

Re: Stable backports

[Joseph Salisbury]

On 6/20/23 11:03, Sebastian Andrzej Siewior wrote:
> Hi,
>
> I've been looking over my queue and which patches vanishes (as in
> applied somewhere) and did not show up in the stable tree. Here is a
> list of some suggestions:
>
> - 7eb16f23b9a41 ("io-mapping: don't disable preempt on RT in io_mapping_map_atomic_wc().")
> - 286deb7ec03d9 ("locking/rwbase: Mitigate indefinite writer starvation")
> - 1c0908d8e4416 ("rtmutex: Add acquire semantics for rtmutex lock acquisition slow path")
>    (is in v6.1 but not in v5.15)
> - b8a04a538ed47 ("revert: "softirq: Let ksoftirqd do its job"")
> - 38cdd83a47fb2 ("tracing/timer: Add missing hrtimer modes to decode_hrtimer_mode().")
>
> Sebastian
Hi Sebastian,

Thanks for the heads up on these commits!

It appears v5.15 will need these commits:

d15121be7485 ("revert: "softirq: Let ksoftirqd do its job"")
2951580ba6ad ("tracing/timer: Add missing hrtimer modes to 
decode_hrtimer_mode().")
7eb16f23b9a41 ("io-mapping: don't disable preempt on RT in 
io_mapping_map_atomic_wc().")
286deb7ec03d9 ("locking/rwbase: Mitigate indefinite writer starvation")

The following commit was already added to v5.15 in v5.15.109:

c15737965434 (rtmutex: Add acquire semantics for rtmutex lock 
acquisition slow path)


The latest two commits are still in linux-next and have not landed in 
mainline as of yet (d15121be7485 and 2951580ba6ad).  Should I wait to 
add them to the v5.15-rt stable tree and see if Greg adds them to his 
trees first?

Thanks,

Joe

Re: Stable backports

[Sebastian Andrzej Siewior]

On 2023-06-27 15:14:35 [-0400], Joseph Salisbury wrote:
> Hi Sebastian,
Hi Joseph,

> Thanks for the heads up on these commits!
> 
> It appears v5.15 will need these commits:
> 
> d15121be7485 ("revert: "softirq: Let ksoftirqd do its job"")
> 2951580ba6ad ("tracing/timer: Add missing hrtimer modes to
> decode_hrtimer_mode().")
> 7eb16f23b9a41 ("io-mapping: don't disable preempt on RT in
> io_mapping_map_atomic_wc().")
> 286deb7ec03d9 ("locking/rwbase: Mitigate indefinite writer starvation")
> 
> The following commit was already added to v5.15 in v5.15.109:
> 
> c15737965434 (rtmutex: Add acquire semantics for rtmutex lock acquisition
> slow path)
> 
> 
> The latest two commits are still in linux-next and have not landed in
> mainline as of yet (d15121be7485 and 2951580ba6ad).  Should I wait to add
> them to the v5.15-rt stable tree and see if Greg adds them to his trees
> first?

They should end up mainline during this merge window. You can wait until
-rc1/-rc2 if you want. If they end-up in the stable-tree, they should
easily vanish from your RT-queue.
Either way, please wait until until they show up in v6.1-RT so patches
flow from the youngest kernel to the oldest.

> Thanks,
> 
> Joe

Sebastian

Re: Stable backports

[Steven Rostedt]

On Tue, 27 Jun 2023 15:14:35 -0400
Joseph Salisbury <joseph.salisbury@canonical.com> wrote:

> 
> The latest two commits are still in linux-next and have not landed in 
> mainline as of yet (d15121be7485 and 2951580ba6ad).  Should I wait to 
> add them to the v5.15-rt stable tree and see if Greg adds them to his 
> trees first?

Well, they are in mainline now ;-)

But I just want to point out that our "upstream" is the next RT kernel
that we have. That is, you should wait till 6.1-rt has a commit before
you take it. 6.1 should wait till Sebastian's 6.3-rt has it.

That is, if a commit goes into Sebastion's tree, it's OK to backport.
But those backports are always added separately from merging a mainline
stable branch.

We merge stable branches by themselves and increment the -rt number
(and we do not need to post a shortlog for that, even though srt does).

Then we add backports as a separate release (and increment the -rt
number again).

-- Steve

Re: Stable backports

[Joseph Salisbury]

On 6/28/23 04:08, Steven Rostedt wrote:
> On Tue, 27 Jun 2023 15:14:35 -0400
> Joseph Salisbury <joseph.salisbury@canonical.com> wrote:
>
>> The latest two commits are still in linux-next and have not landed in
>> mainline as of yet (d15121be7485 and 2951580ba6ad).  Should I wait to
>> add them to the v5.15-rt stable tree and see if Greg adds them to his
>> trees first?
> Well, they are in mainline now ;-)
>
> But I just want to point out that our "upstream" is the next RT kernel
> that we have. That is, you should wait till 6.1-rt has a commit before
> you take it. 6.1 should wait till Sebastian's 6.3-rt has it.
>
> That is, if a commit goes into Sebastion's tree, it's OK to backport.
> But those backports are always added separately from merging a mainline
> stable branch.
>
> We merge stable branches by themselves and increment the -rt number
> (and we do not need to post a shortlog for that, even though srt does).
>
> Then we add backports as a separate release (and increment the -rt
> number again).
>
> -- Steve
>

This all makes sense to me now.  Thanks so much for the feedback, 
Sebastian and Steven!

Re: Stable backports

[Sebastian Andrzej Siewior]

On 2023-06-20 17:03:29 [+0200], To stable-rt@vger.kernel.org wrote:
Hi,

> I've been looking over my queue and which patches vanishes (as in
> applied somewhere) and did not show up in the stable tree. Here is a
> list of some suggestions:
> 
> - 7eb16f23b9a41 ("io-mapping: don't disable preempt on RT in io_mapping_map_atomic_wc().")
> - 286deb7ec03d9 ("locking/rwbase: Mitigate indefinite writer starvation")
> - 1c0908d8e4416 ("rtmutex: Add acquire semantics for rtmutex lock acquisition slow path")
>   (is in v6.1 but not in v5.15)
> - b8a04a538ed47 ("revert: "softirq: Let ksoftirqd do its job"")
> - 38cdd83a47fb2 ("tracing/timer: Add missing hrtimer modes to decode_hrtimer_mode().")

No idea how far backporting got, I would like to extend the list:
- 40cd2835ced28 ("drm/i915: Do not disable preemption for resets")
- 7edeaf858cef4 ("locking/rtmutex: Fix task->pi_waiters integrity")
  Could be routed via stable
- 053ba1b91e511 ("kernel/fork: beware of __put_task_struct calling context")

The following two are just for lockdep:
- 0cce06ba859a5 ("debugobjects,locking: Annotate debug_object_fill_pool() wait type violation")
- a5e446e728e89 ("sched: avoid false lockdep splat in put_task_struct()")

The following three are for mm backport from stable which broke RT and
was noticed during Luis' stable backport. This should be backported so
it is fixed and aligned with upstream:
- a3f6be6e53532 ("printk: Check only for migration in printk_deferred_*().")
- dc93c1f07d485 ("seqlock: Do the lockdep annotation before locking in do_write_seqcount_begin_nested()")
- 4d1139baae8bc ("mm/page_alloc: Use write_seqlock_irqsave() instead write_seqlock() + local_irq_save().")

And finally. Both upstream not sure if they get in via -stable, but I
doubt since they are RT-only and not tagged:
- ab5d47bd41b1d ("bpf: Remove in_atomic() from bpf_link_put().")
- 9d9e522010eb5 ("posix-timers: Prevent RT livelock in itimer_delete()")
- 8ce8849dd1e78 ("posix-timers: Ensure timer ID search-loop limit is valid")

Sebastian