From: Julia Lawall <julia.lawall@lip6.fr> To: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Cc: Joe Perches <joe@perches.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "kernel-janitors@vger.kernel.org" <kernel-janitors@vger.kernel.org> Subject: Re: [PATCH] net: dsa: loop: Check for memory allocation failure Date: Wed, 10 May 2017 12:46:11 +0800 (SGT) [thread overview] Message-ID: <alpine.DEB.2.20.1705101245370.3326@hadrien> (raw) In-Reply-To: <57023eee-a975-5984-dcc5-adee61235c47@wanadoo.fr> [-- Attachment #1: Type: text/plain, Size: 5574 bytes --] 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 >
WARNING: multiple messages have this Message-ID (diff)
From: Julia Lawall <julia.lawall@lip6.fr> To: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Cc: Joe Perches <joe@perches.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "kernel-janitors@vger.kernel.org" <kernel-janitors@vger.kernel.org> Subject: Re: [PATCH] net: dsa: loop: Check for memory allocation failure Date: Wed, 10 May 2017 04:46:11 +0000 [thread overview] Message-ID: <alpine.DEB.2.20.1705101245370.3326@hadrien> (raw) In-Reply-To: <57023eee-a975-5984-dcc5-adee61235c47@wanadoo.fr> [-- Attachment #1: Type: text/plain, Size: 5758 bytes --] 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 >
next prev parent reply other threads:[~2017-05-10 4:46 UTC|newest] Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-05-06 5:29 [PATCH] net: dsa: loop: Check for memory allocation failure Christophe JAILLET 2017-05-06 5:29 ` Christophe JAILLET 2017-05-06 14:45 ` Andrew Lunn 2017-05-06 14:45 ` Andrew Lunn 2017-05-07 23:22 ` Florian Fainelli 2017-05-07 23:22 ` Florian Fainelli 2017-05-08 12:05 ` David Laight 2017-05-08 12:05 ` David Laight 2017-05-08 12:05 ` David Laight 2017-05-08 12:32 ` Julia Lawall 2017-05-08 12:32 ` Julia Lawall 2017-05-08 12:32 ` Julia Lawall 2017-05-08 17:44 ` Joe Perches 2017-05-08 17:44 ` Joe Perches 2017-05-08 17:44 ` Joe Perches 2017-05-08 23:46 ` Julia Lawall 2017-05-08 23:46 ` Julia Lawall 2017-05-08 23:46 ` Julia Lawall 2017-05-09 0:35 ` Florian Fainelli 2017-05-09 0:35 ` Florian Fainelli 2017-05-09 0:35 ` Florian Fainelli 2017-05-09 0:39 ` Julia Lawall 2017-05-09 0:39 ` Julia Lawall 2017-05-09 0:39 ` Julia Lawall 2017-05-09 15:18 ` Joe Perches 2017-05-09 15:18 ` Joe Perches 2017-05-09 15:18 ` Joe Perches 2017-05-10 4:38 ` Christophe JAILLET 2017-05-10 4:38 ` Christophe JAILLET 2017-05-10 4:46 ` Julia Lawall [this message] 2017-05-10 4:46 ` Julia Lawall 2017-05-10 4:54 ` Marion & Christophe JAILLET 2017-05-10 4:54 ` Marion & Christophe JAILLET 2017-05-08 19:01 ` David Miller 2017-05-08 19:01 ` David Miller
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=alpine.DEB.2.20.1705101245370.3326@hadrien \ --to=julia.lawall@lip6.fr \ --cc=christophe.jaillet@wanadoo.fr \ --cc=joe@perches.com \ --cc=kernel-janitors@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.