Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp1530829ybj; Tue, 5 May 2020 23:48:43 -0700 (PDT) X-Google-Smtp-Source: APiQypJqK75wdJR8BBgAmtjya9M9czSMgO1rEV9mZuNDrDTTXRe7HtQEKdXwpfsDccUQvBpfI7X9 X-Received: by 2002:a17:906:310e:: with SMTP id 14mr6207206ejx.177.1588747723324; Tue, 05 May 2020 23:48:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588747723; cv=none; d=google.com; s=arc-20160816; b=vWb3dYGH0cxU6at2QEKEBuvO7FBlI4ZaACsTqk189pLZ9qgTRHJg9PYLND3VYSDVw+ W1yO4ywzb6EcxpqcsCTSwmA1bmkMm3GB3jP0INIXA/34VtIxyqfr/7Of8D08n/fGq5y9 rnIbr8Gy8S/jnQ769Rkol19FBL80T4cLRKGwl7AUU+eXB1CXHdNz12zHbRej5rTaUZNw UPzyv9xEmrzh6oRU1KwIwWax9G3qiIQHuoWFiaPEqX4WJb4UE8OFv1yuNnE/ddLs7QGi 3wVsOBU2uWlsYBHtSzuzpj1iezw+TeaZ4f2JW16wGu4WJBZ2RzNZflGACWGr7yJ/6m+i ccAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=+/CvsVsRvsIe2fdwin42oKRwBiHMUNkSBi3zIOYY4k4=; b=WpRoxvl9rgNe/5+dQjl4vjJwTKSI0gkwuzjeejiC5l7Zh2AfHqAJ88J2+EmlOuGMkb bCSxMjFTkmcd9R5mfUJMyp7risnm2kMNd+r4lKltew3pNIuUhfC+86KShcY4++9I8/sQ 899hG7DRco2+DKukqMgl8dve+eufUQFFjjy/KwTfrbU9Fv6DWWVbiKSnyf4m+eGmr6ST mbEcYBsgkYAI4SGPA/j5W0b2H4uaHvYPC/slBYR0LmfUISHZHUL0dG0aSAPS6KiEFvAB KwTFst8PVB/udzCdrVzTCzDBeBq+1TeFsUSSoU0kIx27tqD+sqz9+ayqSEZIXQuuXYw7 ULNg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bgdev-pl.20150623.gappssmtp.com header.s=20150623 header.b=DT6WmVJO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c23si476577edy.407.2020.05.05.23.48.20; Tue, 05 May 2020 23:48:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@bgdev-pl.20150623.gappssmtp.com header.s=20150623 header.b=DT6WmVJO; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727890AbgEFGqX (ORCPT + 99 others); Wed, 6 May 2020 02:46:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34190 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1725882AbgEFGqV (ORCPT ); Wed, 6 May 2020 02:46:21 -0400 Received: from mail-il1-x144.google.com (mail-il1-x144.google.com [IPv6:2607:f8b0:4864:20::144]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D1146C061A0F for ; Tue, 5 May 2020 23:46:21 -0700 (PDT) Received: by mail-il1-x144.google.com with SMTP id s10so700780iln.11 for ; Tue, 05 May 2020 23:46:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bgdev-pl.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+/CvsVsRvsIe2fdwin42oKRwBiHMUNkSBi3zIOYY4k4=; b=DT6WmVJOSFGWbwoJzWlGLC1MHvldjbW1aPbGsebQDxlwZe7iwnSNTolfUa76eOd29p bY4+DyIu0HM7Ux+b79wpjv1HEfzbH79157RfuHSyksqzSHLknytmZWYPfXFm5QGWRjr4 trPVXMgze6AHFPvmnwrxjqlJKc728qaSJfARZbGbfhF4give+X0eaTP+oNhRMf+5ac8P Arpc631AY/NRljNjuR5I9hcJdirqymusRyVIeUrXArJFWuT3SoexMOmMizUv/8UFF/8J GTpCWHc3c1BWYWTjKwX/5uBZaJK6C+gV4m4MOKsh1M5DtywTmEZjpryYodVi30SRoDCo EcOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=+/CvsVsRvsIe2fdwin42oKRwBiHMUNkSBi3zIOYY4k4=; b=NWBbLW/2B67xdn3iyBS/9E3gHr4GKo/gBf1PA1up3HPP8gPkVcwQV3jxEEDTUhbRpo sWwwJi+NviRPzfWaKUZdYgIc15ghkuJ7iCnq51Rx7OB5R6qY2DXu30+fs7ydWmkml8aq 4+8DDDj7aGBexdaHwljloohzVy1VwVnNPFWiEB22ORAufsldzajNc/TaCYJNPhGYjMlk 2MrkulOEJC8XVKD5m2blxTOXAdgHXytoTcg+ZtyHe6wLALV5+jsqEkyq1BbiuLzMxl/q bS5880avsp5xXLwiWebjSV0tAGmxUEkbRfYgKooQFxCm186VfqzCeeTvZLpxuZaEsTa5 HCqQ== X-Gm-Message-State: AGi0PubyZbJnVwsE+77XoDVRAP2Yxxs4C1HvUhpL/3wjfB8vGUvQdY26 1+yfTsmoKjIcUEkz3GO+Pi92zNh/sAXYi/sS0fU2Cg== X-Received: by 2002:a92:aa07:: with SMTP id j7mr7777424ili.40.1588747581285; Tue, 05 May 2020 23:46:21 -0700 (PDT) MIME-Version: 1.0 References: <20200505140231.16600-1-brgl@bgdev.pl> <20200505140231.16600-6-brgl@bgdev.pl> In-Reply-To: From: Bartosz Golaszewski Date: Wed, 6 May 2020 08:46:10 +0200 Message-ID: Subject: Re: [PATCH 05/11] net: core: provide devm_register_netdev() To: Edwin Peer Cc: Rob Herring , "David S . Miller" , Matthias Brugger , John Crispin , Sean Wang , Mark Lee , Jakub Kicinski , Arnd Bergmann , Fabien Parent , devicetree , Linux Kernel Mailing List , netdev , Linux ARM , linux-mediatek@lists.infradead.org, Bartosz Golaszewski Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org wt., 5 maj 2020 o 21:25 Edwin Peer napisa=C5=82(a= ): > > + > > +static void devm_netdev_release(struct device *dev, void *this) > > +{ > > + struct netdevice_devres *res =3D this; > > + > > + unregister_netdev(res->ndev); > > +} > > + > > +/** > > + * devm_register_netdev - resource managed variant of register_net= dev() > > + * @ndev: device to register > > + * > > + * This is a devres variant of register_netdev() for which the unr= egister > > + * function will be call automatically when the parent device of n= dev > > + * is detached. > > + */ > > +int devm_register_netdev(struct net_device *ndev) > > +{ > > + struct netdevice_devres *dr; > > + int ret; > > + > > + /* struct net_device itself must be devres managed. */ > > + BUG_ON(!(ndev->priv_flags & IFF_IS_DEVRES)); > > + /* struct net_device must have a parent device - it will be the= device > > + * managing this resource. > > + */ > > Catching static programming errors seems like an expensive use of the > last runtime flag in the enum. It would be weird to devres manage the > unregister and not also choose to manage the underlying memory in the > same fashion, so it wouldn't be an obvious mistake to make. If it must > be enforced, one could also iterate over the registered release > functions and check for the presence of devm_free_netdev without > burning the flag. > Hi Edwin, I've submitted this patch some time ago already and was told to check if the underlying memory is managed too. I guess I could try to use devres_find() here though. Re the last bit in priv_flags: is this really a problem though? It's not like struct net_device must remain stable - e.g. we can make priv_flags a bitmap. Bart