lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 14 Sep 2021 17:54:39 +0300 From: Eli Cohen <elic@...dia.com> To: Jakub Kicinski <kuba@...nel.org> CC: <john.hurley@...ronome.com>, <sriharsha.basavapatna@...adcom.com>, <ozsh@...lanox.com>, netdev <netdev@...r.kernel.org> Subject: Re: Questioning requirement for ASSERT_RTNL in indirect code On Tue, Sep 14, 2021 at 07:26:29AM -0700, Jakub Kicinski wrote: > On Tue, 14 Sep 2021 09:05:00 +0300 Eli Cohen wrote: > > 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. > > Currently, with > > 74fc4f828769 ("net: Fix offloading indirect devices dependency on qdisc order creation" > > > > the assert will emit a warning into dmesg with no other noticable > > effect. I am thinking maybe we need to remove this assert. > > > > Comments? > > rtnl_lock must be held unless unlocked_driver_cb is set.
Powered by blists - more mailing lists