Re: [PATCH] net: dsa: loop: Check for memory allocation failure
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(...) ) ... *
Re: [PATCH] net: dsa: loop: Check for memory allocation failure
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@
Re: [PATCH] net: dsa: loop: Check for memory allocation failure
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;
Re: [PATCH] net: dsa: loop: Check for memory allocation failure
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.
Re: [PATCH] net: dsa: loop: Check for memory allocation failure
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
Re: [PATCH] net: dsa: loop: Check for memory allocation failure
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
Re: [PATCH] net: dsa: loop: Check for memory allocation failure
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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Re: [PATCH] net: dsa: loop: Check for memory allocation failure
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; }
Re: [PATCH] net: dsa: loop: Check for memory allocation failure
From: Christophe JAILLET 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 Please do not separate "Fixes: " tags from signoffs and acks with empty lines in the future, thank you. Applied and queued up for -stable.
RE: [PATCH] net: dsa: loop: Check for memory allocation failure
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
RE: [PATCH] net: dsa: loop: Check for memory allocation failure
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
Re: [PATCH] net: dsa: loop: Check for memory allocation failure
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 Acked-by: Florian Fainelli -- Florian
Re: [PATCH] net: dsa: loop: Check for memory allocation failure
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 Reviewed-by: Andrew Lunn Andrew
[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 --- 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