The usage of in_interrupt() in non-core code is phased out. Ideally the information of the calling context should be passed by the callers or the functions be split as appropriate.
The attempt to consolidate the code by passing an arguemnt or by distangling it failed due lack of knowledge about this driver and because the call chains are hard to follow.
As a stop gap use netif_rx_any_context() which invokes the correct code path depending on context and confines the in_interrupt() usage to core code.
Signed-off-by: Sebastian Andrzej Siewior bigeasy@linutronix.de --- net/batman-adv/bridge_loop_avoidance.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/net/batman-adv/bridge_loop_avoidance.c b/net/batman-adv/bridge_loop_avoidance.c index d2de12e527baa..b3411a034d87e 100644 --- a/net/batman-adv/bridge_loop_avoidance.c +++ b/net/batman-adv/bridge_loop_avoidance.c @@ -438,10 +438,7 @@ static void batadv_bla_send_claim(struct batadv_priv *bat_priv, u8 *mac, batadv_add_counter(bat_priv, BATADV_CNT_RX_BYTES, skb->len + ETH_HLEN);
- if (in_interrupt()) - netif_rx(skb); - else - netif_rx_ni(skb); + netif_rx_any_context(skb); out: if (primary_if) batadv_hardif_put(primary_if);
On Saturday, 13 February 2021 18:02:04 CET Sebastian Andrzej Siewior wrote:
The usage of in_interrupt() in non-core code is phased out. Ideally the information of the calling context should be passed by the callers or the functions be split as appropriate.
The attempt to consolidate the code by passing an arguemnt or by distangling it failed due lack of knowledge about this driver and because the call chains are hard to follow.
As a stop gap use netif_rx_any_context() which invokes the correct code path depending on context and confines the in_interrupt() usage to core code.
Thanks, queued up
Kind regards, Sven
On Wednesday, 10 March 2021 18:49:19 CET Sebastian Andrzej Siewior wrote:
On 2021-02-13 18:10:29 [+0100], Sven Eckelmann wrote:
Thanks, queued up
Thank you for that but I don't see it in -next as of today. Did something go wrong?
It is still queued up but not yet forwarded to net-next because it is the only patch at the moment.
Kind regards, Sven
b.a.t.m.a.n@lists.open-mesh.org