Received-SPF: pass (google.com: domain of linux-kernel+bounces-175343-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <a9868190-676e-40a4-93de-2a6f9978e89f@web.de>
Date: Fri, 10 May 2024 08:45:20 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH net-next 5/5] gve: Add flow steering ethtool support
To: Ziwei Xiao <ziweixiao@google.com>, netdev@vger.kernel.org,
 kernel-janitors@vger.kernel.org
Cc: Jeroen de Borst <jeroendb@google.com>,
 Harshitha Ramamurthy <hramamurthy@google.com>,
 Praveen Kaligineedi <pkaligineedi@google.com>,
 Willem de Bruijn <willemb@google.com>, LKML <linux-kernel@vger.kernel.org>,
 "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>,
 Jakub Kicinski <kuba@kernel.org>, John Fraker <jfraker@google.com>,
 Paolo Abeni <pabeni@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
 Shailend Chand <shailend@google.com>, rushilg@google.com
References: <20240507225945.1408516-6-ziweixiao@google.com>
 <3e10ff86-902d-45ed-8671-6544ac4b3930@web.de>
 <CAG-FcCNGsP3FnB6HzrcQxX4kKEHzimYaQnFcBK63z_kFTEQKgw@mail.gmail.com>
Content-Language: en-GB
From: Markus Elfring <Markus.Elfring@web.de>
In-Reply-To: <CAG-FcCNGsP3FnB6HzrcQxX4kKEHzimYaQnFcBK63z_kFTEQKgw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
UI-OutboundReport: notjunk:1;M01:P0:mp12yI6FNfE=;p95rRIu2sD/CMUq04nJNzMAK26N
 TBmPoBNnUhwG3Ac5LBBYZXTYlWklwKVrKaZpwbtasJr5XsGh8yntbIMZBzUxhPX92NEdJFcLT
 5V/o36egFnJ49qpY2PB8k/NeFr7s9QPMyaO5XZNiO3DJB/4nPEDI6evCyii8LEfViDsY4xaJL
 E7rxsGh1eOsy3efRIR05YvZkDkflm7u59go4ivYGWn9i2JmvyVfhfdkMJgNBgUVTvCXVjHAvH
 pB9jxeslFNKzPRSm0rvqJFAMMd0j3zmY3g4c66DfpO6X5okFAHP/asgMJvL1GCGWoA3nLtFiF
 8GsEiyuTd4NKPjedaVNtWfLYnxAgKTxgfaMZhw8RjdT9e6IrVDuRMkm/cMXZFYQ2FC07YI1IJ
 AmKx7UsPOHhNam4ujOwuXHmBDnN1ZGZP8InYlUCY0Nrg23dM4Phfkkpavhnbe/G87kiZP8WnT
 ZH0rMSnHNMqV48ZMZKFJbOpOslJ5gz/9nlpL1LTPSO/chRFK37hN9z1blVz6MHduuJBeEgdfp
 6v1yjlfNy6QZCTihTp3VfSnSyD1RfxubTsZtQxClarYR1/yuaQfhMmmjadvMkC/zKJN6OEj93
 6YTPcl1s3hkh49xhpBQvnPjXUiE2Fm44o+43Rv23Y2cGTM1Fo40vrsVsfBb7AwzYHIJyvwHOo
 EPh2LHzCe/4iVLD+KMXTIHNEQTVZvH06QRcZ/1+3g84NipVke0vgDozt8NLWvK8dASqxAxlNN
 OCccPaEs2fzmd8ATREuHKEPVgbWdKLuh/8IggtgXeVyk+XTowUkd+Ty6AgqbEJAxU4x0EbX/+
 1I6awWZyXAnEJ6wkUa4eOtjgVx3zhYMRHSPuj5S2BOz3A=

>> =E2=80=A6
>>> +++ b/drivers/net/ethernet/google/gve/gve_ethtool.c
>> =E2=80=A6
>>> +static int gve_get_rxnfc(struct net_device *netdev, struct ethtool_rx=
nfc *cmd, u32 *rule_locs)
>>> +{
>>> +     struct gve_priv *priv =3D netdev_priv(netdev);
>>> +     int err =3D 0;
>>> +
>>> +     dev_hold(netdev);
>>> +     rtnl_unlock();
>> =E2=80=A6
>>> +out:
>>> +     rtnl_lock();
>>> +     dev_put(netdev);
>>> +     return err;
>>> +}
>> =E2=80=A6
>>
>> How do you think about to increase the application of scope-based resou=
rce management
>> at such source code places?
>>
> Is the suggestion to combine dev_hold(netdev) together with
> rtnl_unlock()? If so, I think there might be different usages for
> using rtnl_unlock. For example, some drivers will call rtnl_unlock
> after dev_close(netdev). Please correct me if I'm wrong.

How much collateral evolution did you notice according to information from
an article like =E2=80=9CScope-based resource management for the kernel=E2=
=80=9D
by Jonathan Corbet (from 2023-06-15)?
https://lwn.net/Articles/934679/

Would you become interested to extend the usage of resource guards accordi=
ngly?
https://elixir.bootlin.com/linux/v6.9-rc7/source/include/linux/cleanup.h#L=
124

Regards,
Markus