From: Peter Hurley <peter@hurleysoftware.com>
To: Paul Bolle <pebolle@tiscali.nl>, Tilman Schmidt <tilman@imap.cc>,
Sasha Levin <sasha.levin@oracle.com>
Cc: isdn@linux-pingi.de, davem@davemloft.net,
gigaset307x-common@lists.sourceforge.net,
LKML <linux-kernel@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
syzkaller <syzkaller@googlegroups.com>
Subject: Re: gigaset: freeing an active object
Date: Wed, 2 Dec 2015 18:48:17 -0500 [thread overview]
Message-ID: <565F8341.7010704@hurleysoftware.com> (raw)
In-Reply-To: <1448906497.3546.16.camel@tiscali.nl>
On 11/30/2015 01:01 PM, Paul Bolle wrote:
> On ma, 2015-11-30 at 00:23 +0100, Paul Bolle wrote:
>> Relevant part of dmesg attached at the end of this message. This
>> should give me (and Tilman too?) an entry to get to bottom of this.
>> Since this is relevant for anyone with just the ser-gigaset module
>> installed, I hope to do that soon.
>
> I'm planning to send something similar to the attached draft to netdev
> in a few days. It fixes the issue on my machine. Sascha, does it fix
> this issue for syzkaller too?
>
> Should (something like) this go into stable too?
Definitely for stable since it has a userspace triggerable component.
> Any further comments on that draft are appreciated too, of course.
>
>
> Paul Bolle
> ------
> [DRAFT] gigaset: don't free() a struct platform_device
>
> One is not supposed to free() a struct platform_device. Instead one
> should, in the common case, only call platform_device_unregister(). That
> will drop the platform device's reference count. (Actually it's the
> reference count of the embedded kobject that is important here. But for
> users of platform devices that's basically irrelevant.)
>
> So move struct platform_device dev out of struct ser_cardstate, because
> ser_cardstate is (malloc'ed and) free'd.
>
> Reported-by: Sasha Levin <sasha.levin@oracle.com>
> Not-yet-signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> ---
> drivers/isdn/gigaset/ser-gigaset.c | 19 ++++++++++---------
> 1 file changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/isdn/gigaset/ser-gigaset.c b/drivers/isdn/gigaset/ser-gigaset.c
> index 375be509e95f..f8ffa253496e 100644
> --- a/drivers/isdn/gigaset/ser-gigaset.c
> +++ b/drivers/isdn/gigaset/ser-gigaset.c
> @@ -42,8 +42,9 @@ MODULE_PARM_DESC(cidmode, "stay in CID mode when idle");
>
> static struct gigaset_driver *driver;
>
> +static struct platform_device pdev;
> +
> struct ser_cardstate {
> - struct platform_device dev;
> struct tty_struct *tty;
> atomic_t refcnt;
> struct completion dead_cmp;
> @@ -370,8 +371,8 @@ static void gigaset_freecshw(struct cardstate *cs)
> tasklet_kill(&cs->write_tasklet);
> if (!cs->hw.ser)
> return;
> - dev_set_drvdata(&cs->hw.ser->dev.dev, NULL);
> - platform_device_unregister(&cs->hw.ser->dev);
> + dev_set_drvdata(&pdev.dev, NULL);
> + platform_device_unregister(&pdev);
> kfree(cs->hw.ser);
Tilman,
Is there a 1:1 correspondence and lifetime for the embedded platform
device and it's containing memory?
I ask because the typical approach for device teardown is to put the
kfree() in the release method; naturally, that won't work if there
is some other lifetime issue.
Regards,
Peter Hurley
> cs->hw.ser = NULL;
> }
> @@ -401,17 +402,17 @@ static int gigaset_initcshw(struct cardstate *cs)
> }
> cs->hw.ser = scs;
>
> - cs->hw.ser->dev.name = GIGASET_MODULENAME;
> - cs->hw.ser->dev.id = cs->minor_index;
> - cs->hw.ser->dev.dev.release = gigaset_device_release;
> - rc = platform_device_register(&cs->hw.ser->dev);
> + pdev.name = GIGASET_MODULENAME;
> + pdev.id = cs->minor_index;
> + pdev.dev.release = gigaset_device_release;
> + rc = platform_device_register(&pdev);
> if (rc != 0) {
> pr_err("error %d registering platform device\n", rc);
> kfree(cs->hw.ser);
> cs->hw.ser = NULL;
> return rc;
> }
> - dev_set_drvdata(&cs->hw.ser->dev.dev, cs);
> + dev_set_drvdata(&pdev.dev, cs);
>
> tasklet_init(&cs->write_tasklet,
> gigaset_modem_fill, (unsigned long) cs);
> @@ -520,7 +521,7 @@ gigaset_tty_open(struct tty_struct *tty)
> goto error;
> }
>
> - cs->dev = &cs->hw.ser->dev.dev;
> + cs->dev = &pdev.dev;
> cs->hw.ser->tty = tty;
> atomic_set(&cs->hw.ser->refcnt, 1);
> init_completion(&cs->hw.ser->dead_cmp);
>
next prev parent reply other threads:[~2015-12-02 23:48 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-27 15:19 gigaset: freeing an active object Sasha Levin
2015-11-27 17:57 ` Paul Bolle
2015-11-27 18:15 ` Sasha Levin
2015-11-28 0:28 ` Paul Bolle
2015-11-28 1:20 ` Peter Hurley
2015-11-28 1:27 ` Sasha Levin
2015-11-29 14:36 ` Dmitry Vyukov
2015-11-29 15:30 ` Tilman Schmidt
2015-11-29 18:22 ` Peter Hurley
2015-11-29 18:38 ` Tilman Schmidt
2015-11-29 18:47 ` Tilman Schmidt
2015-11-29 20:26 ` Paul Bolle
2015-11-29 23:23 ` Paul Bolle
2015-11-29 23:23 ` Paul Bolle
2015-11-30 18:01 ` Paul Bolle
2015-11-30 18:30 ` Tilman Schmidt
2015-11-30 21:07 ` Paul Bolle
2015-12-01 9:30 ` Tilman Schmidt
2015-12-01 10:05 ` Paul Bolle
2015-12-02 23:48 ` Peter Hurley [this message]
2015-12-06 13:31 ` Paul Bolle
2015-12-06 15:29 ` Tilman Schmidt
2015-12-06 20:12 ` Paul Bolle
2015-12-07 9:27 ` Tilman Schmidt
2015-12-07 12:25 ` Paul Bolle
2015-12-07 18:40 ` Tilman Schmidt
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=565F8341.7010704@hurleysoftware.com \
--to=peter@hurleysoftware.com \
--cc=davem@davemloft.net \
--cc=gigaset307x-common@lists.sourceforge.net \
--cc=isdn@linux-pingi.de \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pebolle@tiscali.nl \
--cc=sasha.levin@oracle.com \
--cc=syzkaller@googlegroups.com \
--cc=tilman@imap.cc \
/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.