On Mon, Apr 25, 2022 at 10:20 AM Lukas Wunner <lukas@xxxxxxxxx> wrote: > > On Mon, Apr 25, 2022 at 05:18:51PM +0200, Jann Horn wrote: > > Well, it's not quite a refcount. It's a count that can be incremented > > and decremented but can't be read while the device is alive, and then > > at some point it turns into a count that can be read and decremented > > but can't be incremented > > Pardon me for being dense, but most other subsystems use the refcounting > built into struct device (or rather, its kobject) and tear it down > when the refcount reaches zero (e.g. pci_release_dev(), spidev_release()). > > What's the rationale for struct net_device rolling its own refcounting? > Historic artifact? Yes, probably. This was there way before new fancy mechanisms were invented. > > > I think a lot of these issues would solve themselves if that was done away > with and replaced with the generic kobject refcounting. It's a pity that > the tracking infrastructure is now netdev-specific and other subsystems > cannot benefit from it. Make sure that whatever replaces it, heavy dev_hold()/dev_put() users do not come to a crawl. af_packet is using this stuff. Some users want to send millions of packets per second, without having to bypass the kernel because it is suddenly too slow. > > Thanks, > > Lukas
