From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
"David S . Miller" <davem@davemloft.net>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Subject: Re: [PATCH] net: phy: mdio_bus: add missing device_del() in mdiobus_register() error handling
Date: Mon, 11 Feb 2019 15:31:59 +0100 [thread overview]
Message-ID: <20190211153159.6b13a687@windsurf> (raw)
In-Reply-To: <20190116154439.GA29244@lunn.ch>
Hello Andrew,
On Wed, 16 Jan 2019 16:44:39 +0100
Andrew Lunn <andrew@lunn.ch> wrote:
> > On Wed, 16 Jan 2019 15:48:29 +0100, Andrew Lunn wrote:
> >
> > > Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> > >
> > > However, i wounder if it makes sense to add a label before the
> > > existing device_del() at the end of the function, and convert this,
> > > and the case above into a goto? That might scale better, avoiding the
> > > same issue in the future?
> >
> > That's another option indeed.
> >
> > Hmm, now that I looked at it, I think we should use device_unregister()
> > instead. device_unregister() does both device_del() and put_device().
>
> Hi Thomas
>
> device_unregister() does seem symmetrical with device_register() which
> is what we are trying to undo.
Even if DaveM already merged my simple fix, I had a further look at
whether we should be using device_unregister(), and in fact we should
not, but not really for a good reason: because the mdio API is not very
symmetrical.
The typical flow is:
probe() {
bus = mdiobus_alloc();
if (!bus)
return -ENOMEM;
ret = mdiobus_register(&bus);
if (ret) {
mdiobus_free(bus);
...
}
remove() {
mdiobus_unregister();
mdiobus_free();
}
mdiobus_alloc() only does memory allocation, i.e it has no side effects
on the device model data structures.
mdiobus_register() does a device_register(). If it fails, it only
cleans up with a device_del(), i.e it doesn't do the put_device() that
it should do to fully "undo" its effect.
mdiobus_unregister() does a device_del(), i.e it also doesn't do the
opposite of mdiobus_register(), which should be device_del() +
put_device() (device_unregister() is a shortcut for both).
mdiobus_free() does the put_device()
So:
* mdiobus_alloc() / mdiobus_free() are not symmetrical in terms of
their interaction with the device model data structures
* On error, mdiobus_register() leaves a non-zero reference count to the
bus->dev structure, which will be freed up by mdiobus_free()
* mdiobus_unregister() leaves a non-zero reference count to the
bus->dev structure, which will be freed up by mdiobus_free()
So, if we were to use device_unregister() in the error path of
mdiobus_register() and in mdiobus_unregister(), it would break how
mdiobus_free() works.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2019-02-11 15:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-16 9:53 [PATCH] net: phy: mdio_bus: add missing device_del() in mdiobus_register() error handling Thomas Petazzoni
2019-01-16 14:48 ` Andrew Lunn
2019-01-16 15:18 ` Thomas Petazzoni
2019-01-16 15:44 ` Andrew Lunn
2019-02-11 14:31 ` Thomas Petazzoni [this message]
2019-02-15 1:23 ` Andrew Lunn
2019-01-18 19:08 ` David Miller
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=20190211153159.6b13a687@windsurf \
--to=thomas.petazzoni@bootlin.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=paul.kocialkowski@bootlin.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).