Re: [PATCH net-next 18/32] netfilter: egress: avoid a lockdep splat

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 1/9/22 15:16, Pablo Neira Ayuso wrote:
From: Florian Westphal <fw@xxxxxxxxx>

include/linux/netfilter_netdev.h:97 suspicious rcu_dereference_check() usage!
2 locks held by sd-resolve/1100:
  0: ..(rcu_read_lock_bh){1:3}, at: ip_finish_output2
  1: ..(rcu_read_lock_bh){1:3}, at: __dev_queue_xmit
  __dev_queue_xmit+0 ..

The helper has two callers, one uses rcu_read_lock, the other
rcu_read_lock_bh().  Annotate the dereference to reflect this.

Fixes: 42df6e1d221dd ("netfilter: Introduce egress hook")
Signed-off-by: Florian Westphal <fw@xxxxxxxxx>
Signed-off-by: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
---
  include/linux/netfilter_netdev.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/netfilter_netdev.h b/include/linux/netfilter_netdev.h
index b71b57a83bb4..b4dd96e4dc8d 100644
--- a/include/linux/netfilter_netdev.h
+++ b/include/linux/netfilter_netdev.h
@@ -94,7 +94,7 @@ static inline struct sk_buff *nf_hook_egress(struct sk_buff *skb, int *rc,
  		return skb;
  #endif
- e = rcu_dereference(dev->nf_hooks_egress);
+	e = rcu_dereference_check(dev->nf_hooks_egress, rcu_read_lock_bh_held());
  	if (!e)
  		return skb;


It seems other rcu_dereference() uses will also trigger lockdep splat.


nft_do_chain()

...

if (genbit)

    blob = rcu_dereference(chain->blob_gen_1);

else

   blob = rcu_dereference(chain->blob_gen_0);

I wonder how many other places will need a fix ?





[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux