From: Dan Carpenter <dan.carpenter@oracle.com>
To: Dongliang Mu <mudongliangabcd@gmail.com>
Cc: syzbot+08a7d8b51ea048a74ffb@syzkaller.appspotmail.com,
linux-kernel <linux-kernel@vger.kernel.org>,
alsa-devel@alsa-project.org, tiwai@suse.com
Subject: Re: [PATCH] ALSA: control led: fix memory leak in snd_ctl_led_register
Date: Mon, 31 May 2021 10:03:38 +0300 [thread overview]
Message-ID: <20210531070337.GV24442@kadam> (raw)
In-Reply-To: <CAD-N9QWBBP6_Wwi4z3e4yJM-tS54=1=CcvAA+2__Qj8NsTLq9g@mail.gmail.com>
On Mon, May 31, 2021 at 02:20:37PM +0800, Dongliang Mu wrote:
> On Mon, May 31, 2021 at 12:40 PM Dan Carpenter <dan.carpenter@oracle.com> wrote:
> >
> > On Mon, May 31, 2021 at 11:03:36AM +0800, Dongliang Mu wrote:
> > > 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.
> >
> > Did your patch fix the leak? Because my patch should have been
> > equivalent except for it fixes an additional leak in the snd_ctl_led_init()
> > error path.
>
> The syzbot link is [1]. I have tested my patch in the syzbot dashboard
> and my local workspace.
>
> I think the reason why your patch did not work should be
> led_card(struct snd_ctl_led_card) is already freed before returning in
> snd_ctl_led_sysfs_remove, rather than led(struct snd_ctl_led). See the
> implementation of snd_ctl_led_sysfs_remove for some details. Please
> correct me if I make any mistakes.
>
> static void snd_ctl_led_sysfs_remove(struct snd_card *card)
> {
> unsigned int group;
> struct snd_ctl_led_card *led_card;
> struct snd_ctl_led *led;
> char link_name[32];
>
> for (group = 0; group < MAX_LED; group++) {
> led = &snd_ctl_leds[group];
> led_card = led->cards[card->number];
> if (!led_card)
> continue;
> snprintf(link_name, sizeof(link_name), "led-%s", led->name);
> sysfs_remove_link(&card->ctl_dev.kobj, link_name);
> sysfs_remove_link(&led_card->dev.kobj, "card");
> device_del(&led_card->dev);
> put_device(&led_card->dev);
> kfree(led_card);
> led->cards[card->number] = NULL;
> }
> }
This is frustrating to look at because it's not a diff so it doesn't
show what you changed. I think you are saying that you added the
put_device(&led_card->dev);. That's true. There are some other leaks
as well. We should just fix them all. Use device_unregister() because
it's cleaner.
If both device_initialize() and device_add() succeed then call
device_unregister() to unwind.
diff --git a/sound/core/control_led.c b/sound/core/control_led.c
index 25f57c14f294..561fe45e4449 100644
--- a/sound/core/control_led.c
+++ b/sound/core/control_led.c
@@ -700,7 +700,7 @@ static void snd_ctl_led_sysfs_remove(struct snd_card *card)
snprintf(link_name, sizeof(link_name), "led-%s", led->name);
sysfs_remove_link(&card->ctl_dev.kobj, link_name);
sysfs_remove_link(&led_card->dev.kobj, "card");
- device_del(&led_card->dev);
+ device_unregister(&led_card->dev);
kfree(led_card);
led->cards[card->number] = NULL;
}
@@ -739,9 +739,9 @@ static int __init snd_ctl_led_init(void)
put_device(&led->dev);
for (; group > 0; group--) {
led = &snd_ctl_leds[group - 1];
- device_del(&led->dev);
+ device_unregister(&led->dev);
}
- device_del(&snd_ctl_led_dev);
+ device_unregister(&snd_ctl_led_dev);
return -ENOMEM;
}
}
@@ -767,9 +767,9 @@ 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_unregister(&led->dev);
}
- device_del(&snd_ctl_led_dev);
+ device_unregister(&snd_ctl_led_dev);
snd_ctl_led_clean(NULL);
}
WARNING: multiple messages have this Message-ID (diff)
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Dongliang Mu <mudongliangabcd@gmail.com>
Cc: perex@perex.cz, tiwai@suse.com, alsa-devel@alsa-project.org,
linux-kernel <linux-kernel@vger.kernel.org>,
syzbot+08a7d8b51ea048a74ffb@syzkaller.appspotmail.com
Subject: Re: [PATCH] ALSA: control led: fix memory leak in snd_ctl_led_register
Date: Mon, 31 May 2021 10:03:38 +0300 [thread overview]
Message-ID: <20210531070337.GV24442@kadam> (raw)
In-Reply-To: <CAD-N9QWBBP6_Wwi4z3e4yJM-tS54=1=CcvAA+2__Qj8NsTLq9g@mail.gmail.com>
On Mon, May 31, 2021 at 02:20:37PM +0800, Dongliang Mu wrote:
> On Mon, May 31, 2021 at 12:40 PM Dan Carpenter <dan.carpenter@oracle.com> wrote:
> >
> > On Mon, May 31, 2021 at 11:03:36AM +0800, Dongliang Mu wrote:
> > > 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.
> >
> > Did your patch fix the leak? Because my patch should have been
> > equivalent except for it fixes an additional leak in the snd_ctl_led_init()
> > error path.
>
> The syzbot link is [1]. I have tested my patch in the syzbot dashboard
> and my local workspace.
>
> I think the reason why your patch did not work should be
> led_card(struct snd_ctl_led_card) is already freed before returning in
> snd_ctl_led_sysfs_remove, rather than led(struct snd_ctl_led). See the
> implementation of snd_ctl_led_sysfs_remove for some details. Please
> correct me if I make any mistakes.
>
> static void snd_ctl_led_sysfs_remove(struct snd_card *card)
> {
> unsigned int group;
> struct snd_ctl_led_card *led_card;
> struct snd_ctl_led *led;
> char link_name[32];
>
> for (group = 0; group < MAX_LED; group++) {
> led = &snd_ctl_leds[group];
> led_card = led->cards[card->number];
> if (!led_card)
> continue;
> snprintf(link_name, sizeof(link_name), "led-%s", led->name);
> sysfs_remove_link(&card->ctl_dev.kobj, link_name);
> sysfs_remove_link(&led_card->dev.kobj, "card");
> device_del(&led_card->dev);
> put_device(&led_card->dev);
> kfree(led_card);
> led->cards[card->number] = NULL;
> }
> }
This is frustrating to look at because it's not a diff so it doesn't
show what you changed. I think you are saying that you added the
put_device(&led_card->dev);. That's true. There are some other leaks
as well. We should just fix them all. Use device_unregister() because
it's cleaner.
If both device_initialize() and device_add() succeed then call
device_unregister() to unwind.
diff --git a/sound/core/control_led.c b/sound/core/control_led.c
index 25f57c14f294..561fe45e4449 100644
--- a/sound/core/control_led.c
+++ b/sound/core/control_led.c
@@ -700,7 +700,7 @@ static void snd_ctl_led_sysfs_remove(struct snd_card *card)
snprintf(link_name, sizeof(link_name), "led-%s", led->name);
sysfs_remove_link(&card->ctl_dev.kobj, link_name);
sysfs_remove_link(&led_card->dev.kobj, "card");
- device_del(&led_card->dev);
+ device_unregister(&led_card->dev);
kfree(led_card);
led->cards[card->number] = NULL;
}
@@ -739,9 +739,9 @@ static int __init snd_ctl_led_init(void)
put_device(&led->dev);
for (; group > 0; group--) {
led = &snd_ctl_leds[group - 1];
- device_del(&led->dev);
+ device_unregister(&led->dev);
}
- device_del(&snd_ctl_led_dev);
+ device_unregister(&snd_ctl_led_dev);
return -ENOMEM;
}
}
@@ -767,9 +767,9 @@ 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_unregister(&led->dev);
}
- device_del(&snd_ctl_led_dev);
+ device_unregister(&snd_ctl_led_dev);
snd_ctl_led_clean(NULL);
}
next prev parent reply other threads:[~2021-05-31 7:04 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-28 13:17 [PATCH] ALSA: control led: fix memory leak in snd_ctl_led_register Dongliang Mu
2021-05-28 13:33 ` Dan Carpenter
2021-05-28 13:33 ` Dan Carpenter
2021-05-28 13:50 ` Dongliang Mu
2021-05-28 13:50 ` Dongliang Mu
2021-05-28 14:05 ` Dan Carpenter
2021-05-28 14:05 ` Dan Carpenter
2021-05-28 21:35 ` 慕冬亮
2021-05-28 21:35 ` 慕冬亮
2021-05-31 3:03 ` Dongliang Mu
2021-05-31 3:03 ` Dongliang Mu
2021-05-31 4:40 ` Dan Carpenter
2021-05-31 4:40 ` Dan Carpenter
2021-05-31 6:20 ` Dongliang Mu
2021-05-31 6:20 ` Dongliang Mu
2021-05-31 7:03 ` Dan Carpenter [this message]
2021-05-31 7:03 ` Dan Carpenter
2021-05-31 7:34 ` Dongliang Mu
2021-05-31 7:34 ` Dongliang Mu
2021-05-31 8:08 ` Dongliang Mu
2021-05-31 8:08 ` Dongliang Mu
2021-05-31 8:46 ` Dan Carpenter
2021-05-31 8:46 ` Dan Carpenter
2021-05-31 9:10 ` Dongliang Mu
2021-05-31 9:10 ` Dongliang Mu
2021-05-31 9:38 ` Dan Carpenter
2021-05-31 9:38 ` Dan Carpenter
2021-05-31 10:35 ` Dongliang Mu
2021-05-31 10:35 ` Dongliang Mu
2021-05-31 10:43 ` Dan Carpenter
2021-05-31 10:43 ` Dan Carpenter
2021-05-31 10:59 ` Dongliang Mu
2021-05-31 10:59 ` Dongliang Mu
2021-05-31 8:12 ` Dan Carpenter
2021-05-31 8:12 ` Dan Carpenter
2021-05-31 4:36 ` Dan Carpenter
2021-05-31 4:36 ` Dan Carpenter
2021-05-31 11:01 ` Dan Carpenter
2021-05-31 11:01 ` Dan Carpenter
2021-05-31 11:07 ` Dan Carpenter
2021-05-31 11:07 ` Dan Carpenter
2021-05-31 11:11 ` Dongliang Mu
2021-05-31 11:11 ` Dongliang Mu
2021-06-01 13:17 ` Dongliang Mu
2021-06-01 13:17 ` Dongliang Mu
2021-06-01 13:46 ` Dan Carpenter
2021-06-01 13:46 ` Dan Carpenter
2021-06-01 14:19 ` Dongliang Mu
2021-06-01 14:19 ` Dongliang Mu
2021-06-01 14:43 ` Dan Carpenter
2021-06-01 14:43 ` Dan Carpenter
2021-06-01 15:52 ` Dongliang Mu
2021-06-01 15:52 ` Dongliang Mu
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=20210531070337.GV24442@kadam \
--to=dan.carpenter@oracle.com \
--cc=alsa-devel@alsa-project.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mudongliangabcd@gmail.com \
--cc=syzbot+08a7d8b51ea048a74ffb@syzkaller.appspotmail.com \
--cc=tiwai@suse.com \
/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: link
Be 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.