Date:   Wed, 10 May 2017 06:54:12 +0200
From:   Marion & Christophe JAILLET <christophe.jaillet@...adoo.fr>
To:     Julia Lawall <julia.lawall@...6.fr>
Cc:     Joe Perches <joe@...ches.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kernel-janitors@...r.kernel.org" <kernel-janitors@...r.kernel.org>
Subject: 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(...)
>> )
>>   ...
>> *  return -EPROBE_DEFER;
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >

Powered by blists - more mailing lists