On Sat, May 29, 2021 at 5:35 AM 慕冬亮 mudongliangabcd@gmail.com wrote:
On May 28, 2021, at 10:05 PM, Dan Carpenter dan.carpenter@oracle.com wrote:
On Fri, May 28, 2021 at 09:50:49PM +0800, Dongliang Mu wrote:
Can you please give some advise on how to fix this WARN issue?
But it feels like it spoils the fun if I write the commit... Anyway:
It’s fine. I am still in the learning process. It’s also good to learn experience by comparing your patch and my patch.
regards, dan carpenter
diff --git a/sound/core/control_led.c b/sound/core/control_led.c index 25f57c14f294..dd357abc1b58 100644 --- a/sound/core/control_led.c +++ b/sound/core/control_led.c @@ -740,6 +740,7 @@ static int __init snd_ctl_led_init(void) for (; group > 0; group--) { led = &snd_ctl_leds[group - 1]; device_del(&led->dev);
device_put(&led->dev); } device_del(&snd_ctl_led_dev); return -ENOMEM;@@ -768,6 +769,7 @@ static void __exit snd_ctl_led_exit(void) for (group = 0; group < MAX_LED; group++) { led = &snd_ctl_leds[group]; device_del(&led->dev);
device_put(&led->dev); } device_del(&snd_ctl_led_dev); snd_ctl_led_clean(NULL);
Hi Dan,
I tried this patch, and it still triggers the memleak. My understanding is that the device object is already freed in the snd_ctl_led_sysfs_remove.
Does this patch mean I should add device_put in the init and exit function other than snd_ctl_led_sysfs_remove? This will cause device_release bypass the release method checking?