[PATCH v5.10-rt] rt: fix build issue in be2net

[PATCH v5.10-rt] rt: fix build issue in be2net

[Luis Claudio R. Goncalves]

While working on v5.10.235-rt128-rc1 I noticed a build problem with
CONFIG_BE2NET enabled. Upon inspection I noticed commit 7cfae8627511
("be2net: fix sleeping while atomic bugs in be_ndo_bridge_getlink"),
from v5.10.235, which contains the following statement:

	return spin_unlock_bh(&adapter->mcc_lock);

The compiler complains when trying to expand the macro spin_unlock_bh()
in that context, requiring a fix similar to commit 386242acb15e ("rt: fix
build issue in at_hdmac"). This problem is specific to v5.10-rt.

Fixes: 7cfae8627511 ("be2net: fix sleeping while atomic bugs in be_ndo_bridge_getlink")
Signed-off-by: Luis Claudio R. Goncalves <lgoncalv@redhat.com>
---

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)?


diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c b/drivers/net/ethernet/emulex/benet/be_cmds.c
index 9812a9a5d033..3068ccd37034 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -875,9 +875,10 @@ static int be_cmd_lock(struct be_adapter *adapter)
 /* Must be used only in process context */
 static void be_cmd_unlock(struct be_adapter *adapter)
 {
-	if (use_mcc(adapter))
-		return spin_unlock_bh(&adapter->mcc_lock);
-	else
+	if (use_mcc(adapter)) {
+		spin_unlock_bh(&adapter->mcc_lock);
+		return;
+	} else
 		return mutex_unlock(&adapter->mbox_lock);
 }
 

Re: [PATCH v5.10-rt] rt: fix build issue in be2net

[Sebastian Andrzej Siewior]

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.

The v5.4 should be also affected, right?

Sebastian

Re: [PATCH v5.10-rt] rt: fix build issue in be2net

[Luis Claudio R. Goncalves]

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---