Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1636831 > unrolled thread

[PATCH] net: dsa: loop: Check for memory allocation failure

Back to article view | Back to linux.kernel

Contents

  [PATCH] net: dsa: loop: Check for memory allocation failure Christophe JAILLET <christophe.jaillet@wanadoo.fr> - 2017-05-06 07:40 +0200
    Re: [PATCH] net: dsa: loop: Check for memory allocation failure Andrew Lunn <andrew@lunn.ch> - 2017-05-06 16:50 +0200
    Re: [PATCH] net: dsa: loop: Check for memory allocation failure Florian Fainelli <f.fainelli@gmail.com> - 2017-05-08 01:30 +0200
    RE: [PATCH] net: dsa: loop: Check for memory allocation failure David Laight <David.Laight@ACULAB.COM> - 2017-05-08 14:10 +0200
      RE: [PATCH] net: dsa: loop: Check for memory allocation failure Julia Lawall <julia.lawall@lip6.fr> - 2017-05-08 14:40 +0200
        Re: [PATCH] net: dsa: loop: Check for memory allocation failure Joe Perches <joe@perches.com> - 2017-05-08 21:50 +0200
          Re: [PATCH] net: dsa: loop: Check for memory allocation failure Julia Lawall <julia.lawall@lip6.fr> - 2017-05-09 01:50 +0200
            Re: [PATCH] net: dsa: loop: Check for memory allocation failure Florian Fainelli <f.fainelli@gmail.com> - 2017-05-09 02:40 +0200
              Re: [PATCH] net: dsa: loop: Check for memory allocation failure Julia Lawall <julia.lawall@lip6.fr> - 2017-05-09 02:50 +0200
              Re: [PATCH] net: dsa: loop: Check for memory allocation failure Joe Perches <joe@perches.com> - 2017-05-09 17:20 +0200
                Re: [PATCH] net: dsa: loop: Check for memory allocation failure Christophe JAILLET <christophe.jaillet@wanadoo.fr> - 2017-05-10 06:40 +0200
                  Re: [PATCH] net: dsa: loop: Check for memory allocation failure Julia Lawall <julia.lawall@lip6.fr> - 2017-05-10 06:50 +0200
                    Re: [PATCH] net: dsa: loop: Check for memory allocation failure Marion & Christophe JAILLET <christophe.jaillet@wanadoo.fr> - 2017-05-10 07:00 +0200
    Re: [PATCH] net: dsa: loop: Check for memory allocation failure David Miller <davem@davemloft.net> - 2017-05-08 21:10 +0200

#1636831 — [PATCH] net: dsa: loop: Check for memory allocation failure

If 'devm_kzalloc' fails, a NULL pointer will be dereferenced.
Return -ENOMEM instead, as done for some other memory allocation just a
few lines above.

Fixes: 98cd1552ea27 ("net: dsa: Mock-up driver")

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
 drivers/net/dsa/dsa_loop.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/dsa/dsa_loop.c b/drivers/net/dsa/dsa_loop.c
index f0fc4de4fc9a..a19e1781e9bb 100644
--- a/drivers/net/dsa/dsa_loop.c
+++ b/drivers/net/dsa/dsa_loop.c
@@ -256,6 +256,9 @@ static int dsa_loop_drv_probe(struct mdio_device *mdiodev)
 		return -ENOMEM;
 
 	ps = devm_kzalloc(&mdiodev->dev, sizeof(*ps), GFP_KERNEL);
+	if (!ps)
+		return -ENOMEM;
+
 	ps->netdev = dev_get_by_name(&init_net, pdata->netdev);
 	if (!ps->netdev)
 		return -EPROBE_DEFER;
-- 
2.11.0

[toc] | [next] | [standalone]

#1636917

On Sat, May 06, 2017 at 07:29:45AM +0200, Christophe JAILLET wrote:
> If 'devm_kzalloc' fails, a NULL pointer will be dereferenced.
> Return -ENOMEM instead, as done for some other memory allocation just a
> few lines above.
> 
> Fixes: 98cd1552ea27 ("net: dsa: Mock-up driver")
> 
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

[toc] | [prev] | [next] | [standalone]

#1637150

Le 05/05/17 à 22:29, Christophe JAILLET a écrit :
> If 'devm_kzalloc' fails, a NULL pointer will be dereferenced.
> Return -ENOMEM instead, as done for some other memory allocation just a
> few lines above.
> 
> Fixes: 98cd1552ea27 ("net: dsa: Mock-up driver")
> 
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>

Acked-by: Florian Fainelli <f.fainelli@gmail.com>
-- 
Florian

[toc] | [prev] | [next] | [standalone]

#1637414

From: Christophe JAILLET
> Sent: 06 May 2017 06:30
> If 'devm_kzalloc' fails, a NULL pointer will be dereferenced.
> Return -ENOMEM instead, as done for some other memory allocation just a
> few lines above.
...
> --- a/drivers/net/dsa/dsa_loop.c
> +++ b/drivers/net/dsa/dsa_loop.c
> @@ -256,6 +256,9 @@ static int dsa_loop_drv_probe(struct mdio_device *mdiodev)
>  		return -ENOMEM;
> 
>  	ps = devm_kzalloc(&mdiodev->dev, sizeof(*ps), GFP_KERNEL);
> +	if (!ps)
> +		return -ENOMEM;
> +
>  	ps->netdev = dev_get_by_name(&init_net, pdata->netdev);
>  	if (!ps->netdev)
>  		return -EPROBE_DEFER;

On the face if it this code leaks like a sieve.

	David

[toc] | [prev] | [next] | [standalone]

#1637425

On Mon, 8 May 2017, David Laight wrote:

> From: Christophe JAILLET
> > Sent: 06 May 2017 06:30
> > If 'devm_kzalloc' fails, a NULL pointer will be dereferenced.
> > Return -ENOMEM instead, as done for some other memory allocation just a
> > few lines above.
> ...
> > --- a/drivers/net/dsa/dsa_loop.c
> > +++ b/drivers/net/dsa/dsa_loop.c
> > @@ -256,6 +256,9 @@ static int dsa_loop_drv_probe(struct mdio_device *mdiodev)
> >  		return -ENOMEM;
> >
> >  	ps = devm_kzalloc(&mdiodev->dev, sizeof(*ps), GFP_KERNEL);
> > +	if (!ps)
> > +		return -ENOMEM;
> > +
> >  	ps->netdev = dev_get_by_name(&init_net, pdata->netdev);
> >  	if (!ps->netdev)
> >  		return -EPROBE_DEFER;
>
> On the face if it this code leaks like a sieve.

I don't think so.  The allocations (dsa_switch_alloc and devm_kzalloc) use
devm functions.

julia

[toc] | [prev] | [next] | [standalone]

#1637675

On Mon, 2017-05-08 at 20:32 +0800, Julia Lawall wrote:
> 
> On Mon, 8 May 2017, David Laight wrote:
> 
> > From: Christophe JAILLET
> > > Sent: 06 May 2017 06:30
> > > If 'devm_kzalloc' fails, a NULL pointer will be dereferenced.
> > > Return -ENOMEM instead, as done for some other memory allocation just a
> > > few lines above.
> > 
> > ...
> > > --- a/drivers/net/dsa/dsa_loop.c
> > > +++ b/drivers/net/dsa/dsa_loop.c
> > > @@ -256,6 +256,9 @@ static int dsa_loop_drv_probe(struct mdio_device *mdiodev)
> > >  		return -ENOMEM;
> > > 
> > >  	ps = devm_kzalloc(&mdiodev->dev, sizeof(*ps), GFP_KERNEL);
> > > +	if (!ps)
> > > +		return -ENOMEM;
> > > +
> > >  	ps->netdev = dev_get_by_name(&init_net, pdata->netdev);
> > >  	if (!ps->netdev)
> > >  		return -EPROBE_DEFER;
> > 
> > On the face if it this code leaks like a sieve.
> 
> I don't think so.  The allocations (dsa_switch_alloc and devm_kzalloc) use
> devm functions.

It's at least wasteful.

Each time -EPROBE_DEFER occurs, another set of calls to
dsa_switch_alloc and dev_kzalloc also occurs.

Perhaps it'd be better to do:

	if (ps->netdev) {
		devm_kfree(&devmdev->dev, ps);
		devm_kfree(&mdiodev->dev, ds);
		return -EPROBE_DEFER;
	}

[toc] | [prev] | [next] | [standalone]

#1637792

On Mon, 8 May 2017, Joe Perches wrote:

> On Mon, 2017-05-08 at 20:32 +0800, Julia Lawall wrote:
> >
> > On Mon, 8 May 2017, David Laight wrote:
> >
> > > From: Christophe JAILLET
> > > > Sent: 06 May 2017 06:30
> > > > If 'devm_kzalloc' fails, a NULL pointer will be dereferenced.
> > > > Return -ENOMEM instead, as done for some other memory allocation just a
> > > > few lines above.
> > >
> > > ...
> > > > --- a/drivers/net/dsa/dsa_loop.c
> > > > +++ b/drivers/net/dsa/dsa_loop.c
> > > > @@ -256,6 +256,9 @@ static int dsa_loop_drv_probe(struct mdio_device *mdiodev)
> > > >  		return -ENOMEM;
> > > >
> > > >  	ps = devm_kzalloc(&mdiodev->dev, sizeof(*ps), GFP_KERNEL);
> > > > +	if (!ps)
> > > > +		return -ENOMEM;
> > > > +
> > > >  	ps->netdev = dev_get_by_name(&init_net, pdata->netdev);
> > > >  	if (!ps->netdev)
> > > >  		return -EPROBE_DEFER;
> > >
> > > On the face if it this code leaks like a sieve.
> >
> > I don't think so.  The allocations (dsa_switch_alloc and devm_kzalloc) use
> > devm functions.
>
> It's at least wasteful.
>
> Each time -EPROBE_DEFER occurs, another set of calls to
> dsa_switch_alloc and dev_kzalloc also occurs.
>
> Perhaps it'd be better to do:
>
> 	if (ps->netdev) {
> 		devm_kfree(&devmdev->dev, ps);
> 		devm_kfree(&mdiodev->dev, ds);
> 		return -EPROBE_DEFER;
> 	}

Is EPROBE_DEFER handled differently than other kinds of errors?

julia


>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

[toc] | [prev] | [next] | [standalone]

#1637798

On 05/08/2017 04:46 PM, Julia Lawall wrote:
> 
> 
> On Mon, 8 May 2017, Joe Perches wrote:
> 
>> On Mon, 2017-05-08 at 20:32 +0800, Julia Lawall wrote:
>>>
>>> On Mon, 8 May 2017, David Laight wrote:
>>>
>>>> From: Christophe JAILLET
>>>>> Sent: 06 May 2017 06:30
>>>>> If 'devm_kzalloc' fails, a NULL pointer will be dereferenced.
>>>>> Return -ENOMEM instead, as done for some other memory allocation just a
>>>>> few lines above.
>>>>
>>>> ...
>>>>> --- a/drivers/net/dsa/dsa_loop.c
>>>>> +++ b/drivers/net/dsa/dsa_loop.c
>>>>> @@ -256,6 +256,9 @@ static int dsa_loop_drv_probe(struct mdio_device *mdiodev)
>>>>>  		return -ENOMEM;
>>>>>
>>>>>  	ps = devm_kzalloc(&mdiodev->dev, sizeof(*ps), GFP_KERNEL);
>>>>> +	if (!ps)
>>>>> +		return -ENOMEM;
>>>>> +
>>>>>  	ps->netdev = dev_get_by_name(&init_net, pdata->netdev);
>>>>>  	if (!ps->netdev)
>>>>>  		return -EPROBE_DEFER;
>>>>
>>>> On the face if it this code leaks like a sieve.
>>>
>>> I don't think so.  The allocations (dsa_switch_alloc and devm_kzalloc) use
>>> devm functions.
>>
>> It's at least wasteful.
>>
>> Each time -EPROBE_DEFER occurs, another set of calls to
>> dsa_switch_alloc and dev_kzalloc also occurs.
>>
>> Perhaps it'd be better to do:
>>
>> 	if (ps->netdev) {
>> 		devm_kfree(&devmdev->dev, ps);
>> 		devm_kfree(&mdiodev->dev, ds);
>> 		return -EPROBE_DEFER;
>> 	}
> 
> Is EPROBE_DEFER handled differently than other kinds of errors?

In the core device driver model, yes, EPROBE_DEFER is treated
differently than other errors because it puts the driver on a retry queue.

EPROBE_DEFER is already a slow and exceptional path, and this is a
mock-up driver, so I am not sure what value there is in trying to
balance devm_kzalloc() with corresponding devm_kfree()...
-- 
Florian

[toc] | [prev] | [next] | [standalone]

#1637802

On Mon, 8 May 2017, Florian Fainelli wrote:

> On 05/08/2017 04:46 PM, Julia Lawall wrote:
> >
> >
> > On Mon, 8 May 2017, Joe Perches wrote:
> >
> >> On Mon, 2017-05-08 at 20:32 +0800, Julia Lawall wrote:
> >>>
> >>> On Mon, 8 May 2017, David Laight wrote:
> >>>
> >>>> From: Christophe JAILLET
> >>>>> Sent: 06 May 2017 06:30
> >>>>> If 'devm_kzalloc' fails, a NULL pointer will be dereferenced.
> >>>>> Return -ENOMEM instead, as done for some other memory allocation just a
> >>>>> few lines above.
> >>>>
> >>>> ...
> >>>>> --- a/drivers/net/dsa/dsa_loop.c
> >>>>> +++ b/drivers/net/dsa/dsa_loop.c
> >>>>> @@ -256,6 +256,9 @@ static int dsa_loop_drv_probe(struct mdio_device *mdiodev)
> >>>>>  		return -ENOMEM;
> >>>>>
> >>>>>  	ps = devm_kzalloc(&mdiodev->dev, sizeof(*ps), GFP_KERNEL);
> >>>>> +	if (!ps)
> >>>>> +		return -ENOMEM;
> >>>>> +
> >>>>>  	ps->netdev = dev_get_by_name(&init_net, pdata->netdev);
> >>>>>  	if (!ps->netdev)
> >>>>>  		return -EPROBE_DEFER;
> >>>>
> >>>> On the face if it this code leaks like a sieve.
> >>>
> >>> I don't think so.  The allocations (dsa_switch_alloc and devm_kzalloc) use
> >>> devm functions.
> >>
> >> It's at least wasteful.
> >>
> >> Each time -EPROBE_DEFER occurs, another set of calls to
> >> dsa_switch_alloc and dev_kzalloc also occurs.
> >>
> >> Perhaps it'd be better to do:
> >>
> >> 	if (ps->netdev) {
> >> 		devm_kfree(&devmdev->dev, ps);
> >> 		devm_kfree(&mdiodev->dev, ds);
> >> 		return -EPROBE_DEFER;
> >> 	}
> >
> > Is EPROBE_DEFER handled differently than other kinds of errors?
>
> In the core device driver model, yes, EPROBE_DEFER is treated
> differently than other errors because it puts the driver on a retry queue.
>
> EPROBE_DEFER is already a slow and exceptional path, and this is a
> mock-up driver, so I am not sure what value there is in trying to
> balance devm_kzalloc() with corresponding devm_kfree()...

OK, thanks for the explanation.

julia

[toc] | [prev] | [next] | [standalone]

#1638185

On Mon, 2017-05-08 at 17:35 -0700, Florian Fainelli wrote:
> On 05/08/2017 04:46 PM, Julia Lawall wrote:
> > On Mon, 8 May 2017, Joe Perches wrote:
> > > Each time -EPROBE_DEFER occurs, another set of calls to
> > > dsa_switch_alloc and dev_kzalloc also occurs.
> > > 
> > > Perhaps it'd be better to do:
> > > 
> > > 	if (ps->netdev) {
> > > 		devm_kfree(&devmdev->dev, ps);
> > > 		devm_kfree(&mdiodev->dev, ds);
> > > 		return -EPROBE_DEFER;
> > > 	}
> > 
> > Is EPROBE_DEFER handled differently than other kinds of errors?
> 
> In the core device driver model, yes, EPROBE_DEFER is treated
> differently than other errors because it puts the driver on a retry queue.
> 
> EPROBE_DEFER is already a slow and exceptional path, and this is a
> mock-up driver, so I am not sure what value there is in trying to
> balance devm_kzalloc() with corresponding devm_kfree()...

Example code should be as correct as possible.

[toc] | [prev] | [next] | [standalone]

#1638557

Le 09/05/2017 à 17:18, Joe Perches a écrit :
> On Mon, 2017-05-08 at 17:35 -0700, Florian Fainelli wrote:
>> On 05/08/2017 04:46 PM, Julia Lawall wrote:
>>> On Mon, 8 May 2017, Joe Perches wrote:
>>>> Each time -EPROBE_DEFER occurs, another set of calls to
>>>> dsa_switch_alloc and dev_kzalloc also occurs.
>>>>
>>>> Perhaps it'd be better to do:
>>>>
>>>> 	if (ps->netdev) {
>>>> 		devm_kfree(&devmdev->dev, ps);
>>>> 		devm_kfree(&mdiodev->dev, ds);
>>>> 		return -EPROBE_DEFER;
>>>> 	}
>>> Is EPROBE_DEFER handled differently than other kinds of errors?
>> In the core device driver model, yes, EPROBE_DEFER is treated
>> differently than other errors because it puts the driver on a retry queue.
>>
>> EPROBE_DEFER is already a slow and exceptional path, and this is a
>> mock-up driver, so I am not sure what value there is in trying to
>> balance devm_kzalloc() with corresponding devm_kfree()...
> Example code should be as correct as possible.
>
Le 09/05/2017 à 17:18, Joe Perches a écrit :
> On Mon, 2017-05-08 at 17:35 -0700, Florian Fainelli wrote:
>> On 05/08/2017 04:46 PM, Julia Lawall wrote:
>>> On Mon, 8 May 2017, Joe Perches wrote:
>>>> Each time -EPROBE_DEFER occurs, another set of calls to
>>>> dsa_switch_alloc and dev_kzalloc also occurs.
>>>>
>>>> Perhaps it'd be better to do:
>>>>
>>>> 	if (ps->netdev) {
>>>> 		devm_kfree(&devmdev->dev, ps);
>>>> 		devm_kfree(&mdiodev->dev, ds);
>>>> 		return -EPROBE_DEFER;
>>>> 	}
>>> Is EPROBE_DEFER handled differently than other kinds of errors?
>> In the core device driver model, yes, EPROBE_DEFER is treated
>> differently than other errors because it puts the driver on a retry queue.
>>
>> EPROBE_DEFER is already a slow and exceptional path, and this is a
>> mock-up driver, so I am not sure what value there is in trying to
>> balance devm_kzalloc() with corresponding devm_kfree()...
> Example code should be as correct as possible.
>
(* number of people/mailing list in copy has been reduced *)


The coccinelle script below gives the following list of candidates for 
such improvement.

char/hw_random/omap-rng.c
clk/clk-si5351.c
clk/clk-versaclock5.c
crypto/mediatek/mtk-platform.c
devfreq/rk3399_dmc.c
dma/mv_xor_v2.c
dma/omap-dma.c
gpu/drm/arc/arcpgu_hdmi.c
gpu/drm/bridge/dumb-vga-dac.c
gpu/drm/bridge/lvds-encoder.c
gpu/drm/exynos/exynos_dp.c
gpu/drm/exynos/exynos_drm_dsi.c
gpu/drm/imx/dw_hdmi-imx.c
gpu/drm/mediatek/mtk_dpi.c
gpu/drm/mediatek/mtk_drm_ddp_comp.c
gpu/drm/mediatek/mtk_dsi.c
gpu/drm/panel/panel-lvds.c
gpu/drm/panel/panel-simple.c
gpu/drm/panel/panel-sitronix-st7789v.c
gpu/drm/rcar-du/rcar_du_lvdscon.c
gpu/drm/rockchip/cdn-dp-core.c
gpu/drm/rockchip/dw_hdmi-rockchip.c
gpu/drm/sti/sti_hdmi.c
gpu/drm/tegra/sor.c
gpu/drm/tilcdc/tilcdc_panel.c
gpu/drm/vc4/vc4_hdmi.c
gpu/ipu-v3/ipu-common.c
gpu/ipu-v3/ipu-pre.c
gpu/ipu-v3/ipu-prg.c
hwtracing/coresight/coresight-stm.c
i2c/busses/i2c-designware-platdrv.c
i2c/busses/i2c-mv64xxx.c
i2c/muxes/i2c-mux-gpio.c
i2c/muxes/i2c-mux-pinctrl.c
i2c/muxes/i2c-mux-reg.c
iommu/mtk_iommu.c
iommu/mtk_iommu_v1.c
irqchip/qcom-irq-combiner.c
mailbox/mailbox-test.c
media/i2c/mt9m111.c
media/i2c/ov2640.c
media/i2c/ov7670.c
media/i2c/smiapp/smiapp-core.c
media/i2c/soc_camera/imx074.c
media/platform/coda/coda-common.c
media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
media/platform/s5p-cec/s5p_cec.c
media/platform/sti/cec/stih-cec.c
memory/tegra/tegra124-emc.c
mfd/twl6040.c
mtd/nand/lpc32xx_mlc.c
mtd/nand/lpc32xx_slc.c
net/dsa/dsa_loop.c
net/ethernet/mediatek/mtk_eth_soc.c
net/phy/xilinx_gmii2rgmii.c
net/wireless/ti/wlcore/spi.c
pci/host/pcie-iproc-platform.c
phy/phy-exynos5250-sata.c
phy/phy-mt65xx-usb3.c
phy/phy-qcom-qusb2.c
phy/phy-sun4i-usb.c
pinctrl/core.c
pinctrl/pinctrl-at91.c
platform/x86/intel_cht_int33fe.c
power/supply/act8945a_charger.c
power/supply/axp20x_ac_power.c
power/supply/axp20x_battery.c
power/supply/axp288_charger.c
power/supply/bq24190_charger.c
power/supply/cpcap-charger.c
power/supply/gpio-charger.c
soc/bcm/raspberrypi-power.c
thermal/samsung/exynos_tmu.c
tty/serial/8250/8250_dw.c
tty/serial/max310x.c
tty/serial/sccnxp.c
usb/chipidea/ci_hdrc_msm.c
usb/gadget/udc/mv_udc_core.c
usb/host/xhci-mtk.c
usb/mtu3/mtu3_plat.c
usb/musb/sunxi.c
usb/phy/phy-am335x.c
usb/phy/phy-generic.c
usb/phy/phy-twl6030-usb.c
video/backlight/hx8357.c
video/backlight/lp855x_bl.c
video/fbdev/simplefb.c


Coccinelle script :
=================
// find calls to kmalloc or equivalent function
@call@
expression ptr;
position p;
@@

(
*   ptr@p = kmalloc(...)
|
*   ptr@p = kzalloc(...)
|
*   ptr@p = kcalloc(...)
|
*   ptr@p = kmalloc_array(...)
|
*   ptr@p = devm_kmalloc(...)
|
*   ptr@p = devm_kzalloc(...)
|
*   ptr@p = devm_kcalloc(...)
|
*   ptr@p = devm_kmalloc_array(...)
)
  ...
*  return -EPROBE_DEFER;

[toc] | [prev] | [next] | [standalone]

#1638558

[Multipart message — attachments visible in raw view] — view raw

On Wed, 10 May 2017, Christophe JAILLET wrote:

> Le 09/05/2017 à 17:18, Joe Perches a écrit :
> > On Mon, 2017-05-08 at 17:35 -0700, Florian Fainelli wrote:
> > > On 05/08/2017 04:46 PM, Julia Lawall wrote:
> > > > On Mon, 8 May 2017, Joe Perches wrote:
> > > > > Each time -EPROBE_DEFER occurs, another set of calls to
> > > > > dsa_switch_alloc and dev_kzalloc also occurs.
> > > > >
> > > > > Perhaps it'd be better to do:
> > > > >
> > > > > 	if (ps->netdev) {
> > > > > 		devm_kfree(&devmdev->dev, ps);
> > > > > 		devm_kfree(&mdiodev->dev, ds);
> > > > > 		return -EPROBE_DEFER;
> > > > > 	}
> > > > Is EPROBE_DEFER handled differently than other kinds of errors?
> > > In the core device driver model, yes, EPROBE_DEFER is treated
> > > differently than other errors because it puts the driver on a retry queue.
> > >
> > > EPROBE_DEFER is already a slow and exceptional path, and this is a
> > > mock-up driver, so I am not sure what value there is in trying to
> > > balance devm_kzalloc() with corresponding devm_kfree()...
> > Example code should be as correct as possible.
> >
> Le 09/05/2017 à 17:18, Joe Perches a écrit :
> > On Mon, 2017-05-08 at 17:35 -0700, Florian Fainelli wrote:
> > > On 05/08/2017 04:46 PM, Julia Lawall wrote:
> > > > On Mon, 8 May 2017, Joe Perches wrote:
> > > > > Each time -EPROBE_DEFER occurs, another set of calls to
> > > > > dsa_switch_alloc and dev_kzalloc also occurs.
> > > > >
> > > > > Perhaps it'd be better to do:
> > > > >
> > > > > 	if (ps->netdev) {
> > > > > 		devm_kfree(&devmdev->dev, ps);
> > > > > 		devm_kfree(&mdiodev->dev, ds);
> > > > > 		return -EPROBE_DEFER;
> > > > > 	}
> > > > Is EPROBE_DEFER handled differently than other kinds of errors?
> > > In the core device driver model, yes, EPROBE_DEFER is treated
> > > differently than other errors because it puts the driver on a retry queue.
> > >
> > > EPROBE_DEFER is already a slow and exceptional path, and this is a
> > > mock-up driver, so I am not sure what value there is in trying to
> > > balance devm_kzalloc() with corresponding devm_kfree()...
> > Example code should be as correct as possible.
> >
> (* number of people/mailing list in copy has been reduced *)
>
>
> The coccinelle script below gives the following list of candidates for such
> improvement.
>
> char/hw_random/omap-rng.c
> clk/clk-si5351.c
> clk/clk-versaclock5.c
> crypto/mediatek/mtk-platform.c
> devfreq/rk3399_dmc.c
> dma/mv_xor_v2.c
> dma/omap-dma.c
> gpu/drm/arc/arcpgu_hdmi.c
> gpu/drm/bridge/dumb-vga-dac.c
> gpu/drm/bridge/lvds-encoder.c
> gpu/drm/exynos/exynos_dp.c
> gpu/drm/exynos/exynos_drm_dsi.c
> gpu/drm/imx/dw_hdmi-imx.c
> gpu/drm/mediatek/mtk_dpi.c
> gpu/drm/mediatek/mtk_drm_ddp_comp.c
> gpu/drm/mediatek/mtk_dsi.c
> gpu/drm/panel/panel-lvds.c
> gpu/drm/panel/panel-simple.c
> gpu/drm/panel/panel-sitronix-st7789v.c
> gpu/drm/rcar-du/rcar_du_lvdscon.c
> gpu/drm/rockchip/cdn-dp-core.c
> gpu/drm/rockchip/dw_hdmi-rockchip.c
> gpu/drm/sti/sti_hdmi.c
> gpu/drm/tegra/sor.c
> gpu/drm/tilcdc/tilcdc_panel.c
> gpu/drm/vc4/vc4_hdmi.c
> gpu/ipu-v3/ipu-common.c
> gpu/ipu-v3/ipu-pre.c
> gpu/ipu-v3/ipu-prg.c
> hwtracing/coresight/coresight-stm.c
> i2c/busses/i2c-designware-platdrv.c
> i2c/busses/i2c-mv64xxx.c
> i2c/muxes/i2c-mux-gpio.c
> i2c/muxes/i2c-mux-pinctrl.c
> i2c/muxes/i2c-mux-reg.c
> iommu/mtk_iommu.c
> iommu/mtk_iommu_v1.c
> irqchip/qcom-irq-combiner.c
> mailbox/mailbox-test.c
> media/i2c/mt9m111.c
> media/i2c/ov2640.c
> media/i2c/ov7670.c
> media/i2c/smiapp/smiapp-core.c
> media/i2c/soc_camera/imx074.c
> media/platform/coda/coda-common.c
> media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
> media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
> media/platform/s5p-cec/s5p_cec.c
> media/platform/sti/cec/stih-cec.c
> memory/tegra/tegra124-emc.c
> mfd/twl6040.c
> mtd/nand/lpc32xx_mlc.c
> mtd/nand/lpc32xx_slc.c
> net/dsa/dsa_loop.c
> net/ethernet/mediatek/mtk_eth_soc.c
> net/phy/xilinx_gmii2rgmii.c
> net/wireless/ti/wlcore/spi.c
> pci/host/pcie-iproc-platform.c
> phy/phy-exynos5250-sata.c
> phy/phy-mt65xx-usb3.c
> phy/phy-qcom-qusb2.c
> phy/phy-sun4i-usb.c
> pinctrl/core.c
> pinctrl/pinctrl-at91.c
> platform/x86/intel_cht_int33fe.c
> power/supply/act8945a_charger.c
> power/supply/axp20x_ac_power.c
> power/supply/axp20x_battery.c
> power/supply/axp288_charger.c
> power/supply/bq24190_charger.c
> power/supply/cpcap-charger.c
> power/supply/gpio-charger.c
> soc/bcm/raspberrypi-power.c
> thermal/samsung/exynos_tmu.c
> tty/serial/8250/8250_dw.c
> tty/serial/max310x.c
> tty/serial/sccnxp.c
> usb/chipidea/ci_hdrc_msm.c
> usb/gadget/udc/mv_udc_core.c
> usb/host/xhci-mtk.c
> usb/mtu3/mtu3_plat.c
> usb/musb/sunxi.c
> usb/phy/phy-am335x.c
> usb/phy/phy-generic.c
> usb/phy/phy-twl6030-usb.c
> video/backlight/hx8357.c
> video/backlight/lp855x_bl.c
> video/fbdev/simplefb.c
>
>
> Coccinelle script :
> =================
> // find calls to kmalloc or equivalent function
> @call@
> expression ptr;
> position p;
> @@
>
> (
> *   ptr@p = kmalloc(...)
> |
> *   ptr@p = kzalloc(...)
> |
> *   ptr@p = kcalloc(...)
> |
> *   ptr@p = kmalloc_array(...)

Do you get any reports for the above function?  Those would normally just
be memory leaks.

julia

> |
> *   ptr@p = devm_kmalloc(...)
> |
> *   ptr@p = devm_kzalloc(...)
> |
> *   ptr@p = devm_kcalloc(...)
> |
> *   ptr@p = devm_kmalloc_array(...)
> )
>  ...
> *  return -EPROBE_DEFER;
>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

[toc] | [prev] | [next] | [standalone]

#1638560

Le 10/05/2017 à 06:46, Julia Lawall a écrit :
>
> On Wed, 10 May 2017, Christophe JAILLET wrote:
>
>> Le 09/05/2017 à 17:18, Joe Perches a écrit :
>>> On Mon, 2017-05-08 at 17:35 -0700, Florian Fainelli wrote:
>>>> On 05/08/2017 04:46 PM, Julia Lawall wrote:
>>>>> On Mon, 8 May 2017, Joe Perches wrote:
>>>>>> Each time -EPROBE_DEFER occurs, another set of calls to
>>>>>> dsa_switch_alloc and dev_kzalloc also occurs.
>>>>>>
>>>>>> Perhaps it'd be better to do:
>>>>>>
>>>>>> 	if (ps->netdev) {
>>>>>> 		devm_kfree(&devmdev->dev, ps);
>>>>>> 		devm_kfree(&mdiodev->dev, ds);
>>>>>> 		return -EPROBE_DEFER;
>>>>>> 	}
>>>>> Is EPROBE_DEFER handled differently than other kinds of errors?
>>>> In the core device driver model, yes, EPROBE_DEFER is treated
>>>> differently than other errors because it puts the driver on a retry queue.
>>>>
>>>> EPROBE_DEFER is already a slow and exceptional path, and this is a
>>>> mock-up driver, so I am not sure what value there is in trying to
>>>> balance devm_kzalloc() with corresponding devm_kfree()...
>>> Example code should be as correct as possible.
>>>
>> Le 09/05/2017 à 17:18, Joe Perches a écrit :
>>> On Mon, 2017-05-08 at 17:35 -0700, Florian Fainelli wrote:
>>>> On 05/08/2017 04:46 PM, Julia Lawall wrote:
>>>>> On Mon, 8 May 2017, Joe Perches wrote:
>>>>>> Each time -EPROBE_DEFER occurs, another set of calls to
>>>>>> dsa_switch_alloc and dev_kzalloc also occurs.
>>>>>>
>>>>>> Perhaps it'd be better to do:
>>>>>>
>>>>>> 	if (ps->netdev) {
>>>>>> 		devm_kfree(&devmdev->dev, ps);
>>>>>> 		devm_kfree(&mdiodev->dev, ds);
>>>>>> 		return -EPROBE_DEFER;
>>>>>> 	}
>>>>> Is EPROBE_DEFER handled differently than other kinds of errors?
>>>> In the core device driver model, yes, EPROBE_DEFER is treated
>>>> differently than other errors because it puts the driver on a retry queue.
>>>>
>>>> EPROBE_DEFER is already a slow and exceptional path, and this is a
>>>> mock-up driver, so I am not sure what value there is in trying to
>>>> balance devm_kzalloc() with corresponding devm_kfree()...
>>> Example code should be as correct as possible.
>>>
>> (* number of people/mailing list in copy has been reduced *)
>>
>>
>> The coccinelle script below gives the following list of candidates for such
>> improvement.
>>
>> char/hw_random/omap-rng.c
>> clk/clk-si5351.c
>> clk/clk-versaclock5.c
>> crypto/mediatek/mtk-platform.c
>> devfreq/rk3399_dmc.c
>> dma/mv_xor_v2.c
>> dma/omap-dma.c
>> gpu/drm/arc/arcpgu_hdmi.c
>> gpu/drm/bridge/dumb-vga-dac.c
>> gpu/drm/bridge/lvds-encoder.c
>> gpu/drm/exynos/exynos_dp.c
>> gpu/drm/exynos/exynos_drm_dsi.c
>> gpu/drm/imx/dw_hdmi-imx.c
>> gpu/drm/mediatek/mtk_dpi.c
>> gpu/drm/mediatek/mtk_drm_ddp_comp.c
>> gpu/drm/mediatek/mtk_dsi.c
>> gpu/drm/panel/panel-lvds.c
>> gpu/drm/panel/panel-simple.c
>> gpu/drm/panel/panel-sitronix-st7789v.c
>> gpu/drm/rcar-du/rcar_du_lvdscon.c
>> gpu/drm/rockchip/cdn-dp-core.c
>> gpu/drm/rockchip/dw_hdmi-rockchip.c
>> gpu/drm/sti/sti_hdmi.c
>> gpu/drm/tegra/sor.c
>> gpu/drm/tilcdc/tilcdc_panel.c
>> gpu/drm/vc4/vc4_hdmi.c
>> gpu/ipu-v3/ipu-common.c
>> gpu/ipu-v3/ipu-pre.c
>> gpu/ipu-v3/ipu-prg.c
>> hwtracing/coresight/coresight-stm.c
>> i2c/busses/i2c-designware-platdrv.c
>> i2c/busses/i2c-mv64xxx.c
>> i2c/muxes/i2c-mux-gpio.c
>> i2c/muxes/i2c-mux-pinctrl.c
>> i2c/muxes/i2c-mux-reg.c
>> iommu/mtk_iommu.c
>> iommu/mtk_iommu_v1.c
>> irqchip/qcom-irq-combiner.c
>> mailbox/mailbox-test.c
>> media/i2c/mt9m111.c
>> media/i2c/ov2640.c
>> media/i2c/ov7670.c
>> media/i2c/smiapp/smiapp-core.c
>> media/i2c/soc_camera/imx074.c
>> media/platform/coda/coda-common.c
>> media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
>> media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
>> media/platform/s5p-cec/s5p_cec.c
>> media/platform/sti/cec/stih-cec.c
>> memory/tegra/tegra124-emc.c
>> mfd/twl6040.c
>> mtd/nand/lpc32xx_mlc.c
>> mtd/nand/lpc32xx_slc.c
>> net/dsa/dsa_loop.c
>> net/ethernet/mediatek/mtk_eth_soc.c
>> net/phy/xilinx_gmii2rgmii.c
>> net/wireless/ti/wlcore/spi.c
>> pci/host/pcie-iproc-platform.c
>> phy/phy-exynos5250-sata.c
>> phy/phy-mt65xx-usb3.c
>> phy/phy-qcom-qusb2.c
>> phy/phy-sun4i-usb.c
>> pinctrl/core.c
>> pinctrl/pinctrl-at91.c
>> platform/x86/intel_cht_int33fe.c
>> power/supply/act8945a_charger.c
>> power/supply/axp20x_ac_power.c
>> power/supply/axp20x_battery.c
>> power/supply/axp288_charger.c
>> power/supply/bq24190_charger.c
>> power/supply/cpcap-charger.c
>> power/supply/gpio-charger.c
>> soc/bcm/raspberrypi-power.c
>> thermal/samsung/exynos_tmu.c
>> tty/serial/8250/8250_dw.c
>> tty/serial/max310x.c
>> tty/serial/sccnxp.c
>> usb/chipidea/ci_hdrc_msm.c
>> usb/gadget/udc/mv_udc_core.c
>> usb/host/xhci-mtk.c
>> usb/mtu3/mtu3_plat.c
>> usb/musb/sunxi.c
>> usb/phy/phy-am335x.c
>> usb/phy/phy-generic.c
>> usb/phy/phy-twl6030-usb.c
>> video/backlight/hx8357.c
>> video/backlight/lp855x_bl.c
>> video/fbdev/simplefb.c
>>
>>
>> Coccinelle script :
>> =================
>> // find calls to kmalloc or equivalent function
>> @call@
>> expression ptr;
>> position p;
>> @@
>>
>> (
>> *   ptr@p = kmalloc(...)
>> |
>> *   ptr@p = kzalloc(...)
>> |
>> *   ptr@p = kcalloc(...)
>> |
>> *   ptr@p = kmalloc_array(...)
> Do you get any reports for the above function?  Those would normally just
> be memory leaks.
Only one, but the corresponding kfree was in place.

> julia
>
>> |
>> *   ptr@p = devm_kmalloc(...)
>> |
>> *   ptr@p = devm_kzalloc(...)
>> |
>> *   ptr@p = devm_kcalloc(...)
>> |
>> *   ptr@p = devm_kmalloc_array(...)
>> )
>>   ...
>> *  return -EPROBE_DEFER;
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >

[toc] | [prev] | [next] | [standalone]

#1637654

From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Sat,  6 May 2017 07:29:45 +0200

> If 'devm_kzalloc' fails, a NULL pointer will be dereferenced.
> Return -ENOMEM instead, as done for some other memory allocation just a
> few lines above.
> 
> Fixes: 98cd1552ea27 ("net: dsa: Mock-up driver")
> 
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>

Please do not separate "Fixes: " tags from signoffs and acks with
empty lines in the future, thank you.

Applied and queued up for -stable.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web