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
| ||
|
Message-ID: <776c367b-d409-4972-b881-51a1bbbc9898@intel.com> Date: Tue, 24 Oct 2023 19:18:11 -0700 From: "Nambiar, Amritha" <amritha.nambiar@...el.com> To: Jakub Kicinski <kuba@...nel.org> CC: <netdev@...r.kernel.org>, <pabeni@...hat.com>, <sridhar.samudrala@...el.com> Subject: Re: [net-next PATCH v6 06/10] netdev-genl: Add netlink framework functions for napi On 10/24/2023 3:39 PM, Jakub Kicinski wrote: > On Mon, 23 Oct 2023 18:33:50 -0700 Amritha Nambiar wrote: >> + rcu_read_lock(); >> + >> + napi = napi_by_id(napi_id); >> + if (napi) >> + err = netdev_nl_napi_fill_one(rsp, napi, info); >> + else >> + err = -EINVAL; >> + >> + rcu_read_unlock(); > > Is rcu_read_lock always going to be sufficient here? > Reading of the thread, for example, without much locking could > potentially get problematic. I think I was inspired by the napi_busy_loop code which works on napi->state under rcu_read_lock. WRT napi_get_doit here (just thinking aloud), so if we have a reader thread retrieving napi from the global list for a napi_id, and a writer thread (maybe ethtool -L sort which is under rtnl_lock) that changes the napi list... Now, the reader may be working on a stale napi instance, or if the writer still holds lock until freeing memory containing the napi, then the reader may cause a crash... okay, all the more reason for the reader to hold rtnl_lock instead of rcu_read_lock.
Powered by blists - more mailing lists