From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DB9EAC433FE for ; Mon, 25 Apr 2022 17:20:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243274AbiDYRXb (ORCPT ); Mon, 25 Apr 2022 13:23:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57036 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242858AbiDYRX3 (ORCPT ); Mon, 25 Apr 2022 13:23:29 -0400 Received: from bmailout3.hostsharing.net (bmailout3.hostsharing.net [IPv6:2a01:4f8:150:2161:1:b009:f23e:0]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DD373340EA; Mon, 25 Apr 2022 10:20:19 -0700 (PDT) Received: from h08.hostsharing.net (h08.hostsharing.net [83.223.95.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "*.hostsharing.net", Issuer "RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1" (verified OK)) by bmailout3.hostsharing.net (Postfix) with ESMTPS id F284E1032EE24; Mon, 25 Apr 2022 19:20:14 +0200 (CEST) Received: by h08.hostsharing.net (Postfix, from userid 100393) id CB7C711767B; Mon, 25 Apr 2022 19:20:14 +0200 (CEST) Date: Mon, 25 Apr 2022 19:20:14 +0200 From: Lukas Wunner To: Jann Horn Cc: Eric Dumazet , Jakub Kicinski , Paolo Abeni , Oliver Neukum , "David S. Miller" , Oleksij Rempel , netdev , USB list , Andrew Lunn , Jacky Chou , Willy Tarreau , Lino Sanfilippo , Philipp Rosenberger , Heiner Kallweit , Greg Kroah-Hartman Subject: Re: [PATCH] net: linkwatch: ignore events for unregistered netdevs Message-ID: <20220425172014.GA24181@wunner.de> References: <18b3541e5372bc9b9fc733d422f4e698c089077c.1650177997.git.lukas@wunner.de> <9325d344e8a6b1a4720022697792a84e545fef62.camel@redhat.com> <20220423160723.GA20330@wunner.de> <20220425074146.1fa27d5f@kernel.org> <20220425080057.0fc4ef66@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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? 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. Thanks, Lukas