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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YqF5rzIiLCJgW5Gd@nanopsycho>
Date:   Thu, 9 Jun 2022 06:40:15 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com,
        pabeni@...hat.com, dsahern@...nel.org,
        steffen.klassert@...unet.com, jreuter@...na.de,
        razor@...ckwall.org, kgraul@...ux.ibm.com, ivecera@...hat.com,
        jmaloy@...hat.com, ying.xue@...driver.com, lucien.xin@...il.com,
        arnd@...db.de, yajun.deng@...ux.dev, atenart@...nel.org,
        richardsonnick@...gle.com, hkallweit1@...il.com,
        linux-hams@...r.kernel.org, dev@...nvswitch.org,
        linux-s390@...r.kernel.org, tipc-discussion@...ts.sourceforge.net
Subject: Re: [PATCH net-next] net: rename reference+tracking helpers

Wed, Jun 08, 2022 at 04:58:27PM CEST, kuba@...nel.org wrote:
>On Wed, 8 Jun 2022 10:27:15 +0200 Jiri Pirko wrote:
>> Wed, Jun 08, 2022 at 06:39:55AM CEST, kuba@...nel.org wrote:
>> >Netdev reference helpers have a dev_ prefix for historic
>> >reasons. Renaming the old helpers would be too much churn  
>> 
>> Hmm, I think it would be great to eventually rename the rest too in
>> order to maintain unique prefix for netdev things. Why do you think the
>> "churn" would be an issue?
>
>Felt like we're better of moving everyone to the new tracking helpers
>than doing just a pure rename. But I'm not opposed to a pure rename.
>
>> >diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
>> >index 817577e713d7..815738c0e067 100644
>> >--- a/drivers/net/macsec.c
>> >+++ b/drivers/net/macsec.c
>> >@@ -3462,7 +3462,7 @@ static int macsec_dev_init(struct net_device *dev)
>> > 		memcpy(dev->broadcast, real_dev->broadcast, dev->addr_len);
>> > 
>> > 	/* Get macsec's reference to real_dev */
>> >-	dev_hold_track(real_dev, &macsec->dev_tracker, GFP_KERNEL);
>> >+	netdev_hold(real_dev, &macsec->dev_tracker, GFP_KERNEL);  
>> 
>> So we later decide to rename dev_hold() to obey the netdev_*() naming
>> scheme, we would have collision.
>
>dev_hold() should not be used in new code, we should use tracking
>everywhere. Given that we can name the old helpers __netdev_hold().
>
>> Also, seems to me odd to have:
>> OLDPREFIX_x()
>> and
>> NEWPREFIX_x()
>> to be different functions.
>> 
>> For the sake of not making naming mess, could we rather have:
>> netdev_hold_track()
>> or
>> netdev_hold_tr() if the prior is too long
>> ?
>
>See above, one day non-track version should be removed.
>IMO to encourage use of the track-capable API we could keep their names
>short and call the legacy functions __netdev_hold() as I mentioned or
>maybe netdev_hold_notrack().

Okay, that makes sense.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ