Thread (5 messages) flat view 5 messages, 2 authors, 2021-09-14

Re: Questioning requirement for ASSERT_RTNL in indirect code

From: Jakub Kicinski <kuba@kernel.org>
Date: 2021-09-14 15:07:49

On Tue, 14 Sep 2021 17:54:39 +0300 Eli Cohen wrote:
On Tue, Sep 14, 2021 at 07:26:29AM -0700, Jakub Kicinski wrote:
quoted
On Tue, 14 Sep 2021 09:05:00 +0300 Eli Cohen wrote:  
quoted
I see the same assert and the same comment, "All callback list access
should be protected by RTNL.", in the following locations

drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c:1873
drivers/net/ethernet/mellanox/mlx5/core/en/rep/tc.c:303
drivers/net/ethernet/netronome/nfp/flower/offload.c:1770

I assume the source of this comment is the same. Can you guys explain
why is this necessary?  
Because most drivers (all but mlx5?) depend on rtnl_lock for
serializing tc offload operations.
  
But the assert I am referring to is called as part of setting up the
callback that will be used for offload operations, e.g. for adding a new
filter with tc. It's not the actual filter insetion code.

And as far as I can see this call sequence is already serialized by
flow_indr_block_lock.
Hm, indeed, should've looked at the code. There doesn't seem to be
anything on the driver side this is protecting. The assert was added
before the flow/nftables rewrite of the infra, perhaps that's the
answer. IOW the lock did not exist back then.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help