On Mon, Mar 24, 2025 at 09:32:35AM +0100, Sebastian Andrzej Siewior wrote:
> On 2025-03-20 21:09:06 [-0300], Luis Claudio R. Goncalves wrote:
> > Sebastian, Steven, All,
> >
> > Should I apply this solution in a RT update right after I release
> > v5.10.235-rt128 or should I backport the definition of rt locking
> > primitives from a newer PREEMPT_RT patch (say v5.15-rt or v6.1-rt)?
>
> The statement ("return spin_unlock.*") is not very common, there is just
> one "user" even in later kernels.
>
> Backporting the definition (instead of changing the driver) would be
> more consistent with later trees. I'm somewhere between the definition
> backport and what is less work.
How about we compromisse on the workaround for this release and if there is
a new case I revert the two workarounds and perform the backport? Does that
sound reasonable?
> The v5.4 should be also affected, right?
Yes, if the offending commits (below) are backported to v5.4-rt, you will
see the problem:
1582cc3b4805 dmaengine: at_hdmac: Fix concurrency problems by removing atc_complete_all()
7078e935b410 dmaengine: at_hdmac: Fix premature completion of desc in issue_pending
7cfae8627511 be2net: fix sleeping while atomic bugs in be_ndo_bridge_getlink
Luis
> Sebastian
>
---end quoted text---
