From: Simon Horman <horms@kernel.org>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp>,
rafal@milecki.pl, andrew+netdev@lunn.ch, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
bcm-kernel-feedback-list@broadcom.com, netdev@vger.kernel.org
Subject: Re: [PATCH] net: ethernet: bgmac-platform: fix an OF node reference leak
Date: Fri, 13 Dec 2024 13:29:10 +0000 [thread overview]
Message-ID: <20241213132910.GA561418@kernel.org> (raw)
In-Reply-To: <b8604925-d3fb-4994-893c-d34e6185e950@lunn.ch>
On Fri, Dec 13, 2024 at 01:04:42PM +0100, Andrew Lunn wrote:
> > Hi Joe,
> >
> > I agree this is a problem and that it was introduced by the
> > cited commit. But I wonder if we can consider a different approach.
> >
> > I would suggest that rather than using __free the node is explicitly
> > released. Something like this (untested):
> >
> > struct device_node *phy_node;
> >
> > ...
> >
> > phy_node = of_parse_phandle(np, "phy-handle", 0);
> > if (phy_node) {
> > of_node_put(phy_node);
> > bgmac->phy_connect = platform_phy_connect;
> > } ...
> >
> > That is, assuming that it is safe to release phy_node so early.
> > If not, some adjustment should be made to when of_node_put()
> > is called.
> >
> > This is for several reasons;
> >
> > 1. I could be wrong, but I believe your patch kfree's phy_node,
> > but my understanding is that correct operation is to call
> > of_node_put().
>
> Hi Simon
>
> I _think_ that is wrong. More of the magic which i don't really
> like. The cleanup subsystem has to be taught all the types, and what
> operation to perform for each type. Despite the name __free(), i think
> it does actually call of_node_put(). The magic would be more readable
> if it was actually __put(), not __free().
Thanks, TIL.
> > 2. More importantly, there is a preference in Newkorking code
> > not to use __free and similar constructs.
> >
> > "Low level cleanup constructs (such as __free()) can be used when
> > building APIs and helpers, especially scoped iterators. However,
> > direct use of __free() within networking core and drivers is
> > discouraged. Similar guidance applies to declaring variables
> > mid-function.
>
> And this is a good example of why.
>
> Andrew
>
prev parent reply other threads:[~2024-12-13 13:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-12 2:32 [PATCH] net: ethernet: bgmac-platform: fix an OF node reference leak Joe Hattori
2024-12-13 10:55 ` Simon Horman
2024-12-13 12:04 ` Andrew Lunn
2024-12-13 13:29 ` Simon Horman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241213132910.GA561418@kernel.org \
--to=horms@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=andrew@lunn.ch \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=joe@pf.is.s.u-tokyo.ac.jp \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rafal@milecki.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.