| 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
| ||
|
Message-ID: <20140517221450.GA20636@lianli>
Date: Sun, 18 May 2014 00:14:50 +0200
From: Emil Goode <emilgoode@...il.com>
To: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
Cc: walter harms <wharms@....de>, Shawn Guo <shawn.guo@...escale.com>,
Sascha Hauer <kernel@...gutronix.de>,
Russell King <linux@....linux.org.uk>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
kernel-janitors@...r.kernel.org
Subject: Re: [PATCH v2] ARM: imx: fix error handling
Hello Uwe,
On Sat, May 17, 2014 at 09:05:46PM +0200, Uwe Kleine-König wrote:
> Hello Emil,
>
> On Sat, May 17, 2014 at 05:35:40PM +0200, Emil Goode wrote:
> > On Fri, May 16, 2014 at 09:31:39PM +0200, Uwe Kleine-König wrote:
> > > On Fri, May 16, 2014 at 01:49:10PM +0200, walter harms wrote:
> > > > Am 16.05.2014 13:16, schrieb Emil Goode:
> > > > > Hello Walter,
> > > > >
> > > > > On Fri, May 16, 2014 at 12:40:19PM +0200, walter harms wrote:
> > > > >>
> > > > >>
> > > > >> Am 16.05.2014 11:54, schrieb Emil Goode:
> > > > >>> If we fail to allocate struct platform_device pdev we
> > > > >>> dereference it after the goto label err.
> > > > >>>
> > > > >>> I have rearranged the error handling a bit to fix the issue
> > > > >>> and also make it more clear.
> > > > >>>
> > > > >>> Signed-off-by: Emil Goode <emilgoode@...il.com>
> > > > >>> ---
> > > > >>> v2: Changed to return -ENOMEM instead of ret where possible and
> > > > >>> updated the subject line.
> > > > >>>
> > > > >>> arch/arm/mach-imx/devices/platform-ipu-core.c | 22 +++++++++++++---------
> > > > >>> 1 file changed, 13 insertions(+), 9 deletions(-)
> > > > >>>
> > > > >>> diff --git a/arch/arm/mach-imx/devices/platform-ipu-core.c b/arch/arm/mach-imx/devices/platform-ipu-core.c
> > > > >>> index fc4dd7c..68f2a4a 100644
> > > > >>> --- a/arch/arm/mach-imx/devices/platform-ipu-core.c
> > > > >>> +++ b/arch/arm/mach-imx/devices/platform-ipu-core.c
> > > > >>> @@ -77,34 +77,38 @@ struct platform_device *__init imx_alloc_mx3_camera(
> > > > >>>
> > > > >>> pdev = platform_device_alloc("mx3-camera", 0);
> > > > >>> if (!pdev)
> > > > >>> - goto err;
> > > > >>> + return ERR_PTR(-ENOMEM);
> > > > >>>
> > > > >>> pdev->dev.dma_mask = kmalloc(sizeof(*pdev->dev.dma_mask), GFP_KERNEL);
> > > > >>> if (!pdev->dev.dma_mask)
> > > > >>> - goto err;
> > > > >>> + goto put_pdev;
> > > > >>>
> > > > >>> *pdev->dev.dma_mask = DMA_BIT_MASK(32);
> > > > >>> pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> > > > >>>
> > > > >>> ret = platform_device_add_resources(pdev, res, ARRAY_SIZE(res));
> > > > >>> if (ret)
> > > > >>> - goto err;
> > > > >>> + goto free_dma_mask;
> > > > >>>
> > > > >>> if (pdata) {
> > > > >>> struct mx3_camera_pdata *copied_pdata;
> > > > >>>
> > > > >>> ret = platform_device_add_data(pdev, pdata, sizeof(*pdata));
> > > > >>> - if (ret) {
> > > > >>> -err:
> > > > >>> - kfree(pdev->dev.dma_mask);
> > > > >>> - platform_device_put(pdev);
> > > > >>> - return ERR_PTR(-ENODEV);
> > > > >>> - }
> > > > >>> + if (ret)
> > > > >>> + goto free_dma_mask;
> > > > >>> +
> > > > >>> copied_pdata = dev_get_platdata(&pdev->dev);
> > > > >>> copied_pdata->dma_dev = &imx_ipu_coredev->dev;
> > > > >>
> > > > >>
> > > > >> the patch is fine, but what use is this copied_pdata ?
> > > > >> It scope ends next line ?
> > > > >>
> > > > >> re,
> > > > >> wh
> > > > >
> > > > > I also thought that looked a bit odd, but copied_pdata is a temporary
> > > > > pointer to platform_data of the dev struct.
> > > > >
> > > > > dev_get_platdata looks like this:
> > > > >
> > > > > static inline void *dev_get_platdata(const struct device *dev)
> > > > > {
> > > > > return dev->platform_data;
> > > > > }
> > > > >
> > > > > So I believe it's a more compact way of writing:
> > > > >
> > > > > pdev->dev->platform_data->dma_dev = &imx_ipu_coredev->dev;
> > > It's not about compactness. The dev_get_platdata accessor exists to be
> > > used instead of directly accessing dev->platform_data. I admit a comment
> > > would be nice ...
> > >
> > > Anyhow this is all ugly, actually you'd want to have the dma_dev member
> > > already fixed when calling platform_device_add_data. But you cannot
> > > simply do
> > >
> > > pdata->dma_dev = &imx_ipu_coredev->dev;
> > > ret = platform_device_add_data(pdev, pdata, sizeof(*pdata));
> > >
> > > because *pdata is const.
> >
> > Thank you for the explanation. Regarding the possibility of using
> > platform_device_register_full() to simplify this function. It seem to
> > be possible, the following inline function is available to help with this.
> >
> > imx_add_platform_device_dmamask()
> I'd prefer to use platform_device_register_full directly (and let the
> wrapper die).
Ok, will skip the wrapper.
>
> > But as you mentioned above we need to allocate a new platform_device
> > struct before we can assign &imx_ipu_coredev->dev to dma_dev, since
> > pdata is const. I guess this assignment could be done after calling
> > imx_add_platform_device_dmamask() but I don't think that makes the
> No, that won't work, because after platform_device_register_full returns
> you must assume that the device is already bound by a driver. And then
> you must not change platform_data anymore.
I see, thanks for explaining.
>
> The only thing that would work is:
>
> struct mx3_camera_pdata tmppdata;
>
> if (pdata) {
> tmppdata = *pdata;
> tmppdata.dma_dev = &imx_ipu_coredev->dev;
>
> pdata = &tmppdata;
> }
>
> platform_device_register_full(... pdata ...)
You are right, that would work.
Will look at this again tomorrow.
Thank you!
Best regards,
Emil Goode
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists