linux-kernel - Re: [PATCH 5/5] mmc: cavium: Fix probing race with regulator

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: <20170518093924.GA27614@hc>
Date:   Thu, 18 May 2017 11:39:24 +0200
From:   Jan Glauber <jan.glauber@...iumnetworks.com>
To:     Rob Herring <robh+dt@...nel.org>
Cc:     Ulf Hansson <ulf.hansson@...aro.org>,
        David Daney <david.daney@...ium.com>,
        Frank Rowand <frowand.list@...il.com>,
        "Steven J . Hill" <Steven.Hill@...ium.com>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 5/5] mmc: cavium: Fix probing race with regulator

On Wed, May 17, 2017 at 03:41:12PM +0200, Jan Glauber wrote:
> On Tue, May 16, 2017 at 09:37:48AM -0500, Rob Herring wrote:
> > On Tue, May 16, 2017 at 8:38 AM, Jan Glauber
> > <jan.glauber@...iumnetworks.com> wrote:
> > > On Tue, May 16, 2017 at 08:07:50AM -0500, Rob Herring wrote:
> > >> On Tue, May 16, 2017 at 4:36 AM, Jan Glauber <jglauber@...ium.com> wrote:
> > >> > If the regulator probing is not yet finished this driver
> > >> > might catch a -EPROBE_DEFER. Returning after this condition
> > >> > did not remove the created platform device. On a repeated
> > >> > call to the probe function the of_platform_device_create
> > >> > fails.
> > >> >
> > >> > Calling of_platform_device_destroy after EPROBE_DEFER resolves
> > >> > this bug.
> > >> >
> > >> > Signed-off-by: Jan Glauber <jglauber@...ium.com>
> > >> > ---
> > >> >  drivers/mmc/host/cavium-thunderx.c | 4 +++-
> > >> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > >> >
> > >> > diff --git a/drivers/mmc/host/cavium-thunderx.c b/drivers/mmc/host/cavium-thunderx.c
> > >> > index fe3d772..257535e 100644
> > >> > --- a/drivers/mmc/host/cavium-thunderx.c
> > >> > +++ b/drivers/mmc/host/cavium-thunderx.c
> > >> > @@ -137,8 +137,10 @@ static int thunder_mmc_probe(struct pci_dev *pdev,
> > >> >                                 continue;
> > >> >
> > >> >                         ret = cvm_mmc_of_slot_probe(&host->slot_pdev[i]->dev, host);
> > >> > -                       if (ret)
> > >> > +                       if (ret) {
> > >> > +                               of_platform_device_destroy(&host->slot_pdev[i]->dev, NULL);
> > >>
> > >> What if this fails after the 1st iteration of the loop. It's only
> > >> cleaning up the current device.
> > >
> > > The platform device is just a dummy device created directly before
> > > cvm_mmc_of_slot_probe(). So there is no need to cleanup anything else.
> > 
> > So if you have 2 slots, the first slot probes successfully and the 2nd
> > slot defers, then you only need to clean-up the 2nd device/slot? Looks
> > to me like you are leaking the 1st device you alloc.
> 
> OK, got it now. My assumption was that your scenario can't happen in
> reality with EPROBE_DEFER.
> 
> > >
> > > As far as I've seen it the platform code 'tags' the nodes it already
> > > used, but I need the same node to be parsed again on -EPROBE_DEFER.
> > >
> > >> Use devm_of_platform_populate or
> > >> of_platform_populate/of_platform_depopulate instead.
> > >
> > > I'm not sure one of these will work here.
> > 
> > Those functions loop over child nodes and create devices. You are
> > doing the same thing. You'd just need to create all the devices first
> > and then probe them all.
> 
> I'll take a look at devm_of_platform_populate then. If I can use it it
> will solve the leak issue.

Using [devm_]of_platform_populate/of_platform_depopulate would require
a platform driver with its prove/remove functions. I don't think this
would make the driver easier to read as we would then have a platform driver
within a pci driver.

If it is possible to export the of_platform_device_destroy() I would
prefer to fix the leak and stay with of_platform_device_create.

--Jan

> thanks,
> Jan
> 
> > The whole structure here with the dummy devices and how you are
> > initializing things is screwy. IMO, you should be creating actual
> > drivers for the dummy devices.
> > 
> > Rob