From: Cornelia Huck <cornelia.huck@de.ibm.com>
To: "Dave Young" <hidave.darkstar@gmail.com>
Cc: "Gabor Gombas" <gombasg@sztaki.hu>,
"Tejun Heo" <htejun@gmail.com>,
"Al Viro" <viro@zeniv.linux.org.uk>,
linux-kernel@vger.kernel.org, bluez-devel@lists.sourceforge.net,
kay.sievers@vrfy.org, "Greg KH" <greg@kroah.com>,
"Marcel Holtmann" <marcel@holtmann.org>,
davem@davemloft.net
Subject: Re: [Bluez-devel] Oops involving RFCOMM and sysfs
Date: Fri, 18 Jan 2008 10:19:33 +0100 [thread overview]
Message-ID: <20080118101933.258bfae9@gondolin.boeblingen.de.ibm.com> (raw)
In-Reply-To: <a8e1da0801171937r92a1c32l116315a76f334776@mail.gmail.com>
On Fri, 18 Jan 2008 11:37:21 +0800,
"Dave Young" <hidave.darkstar@gmail.com> wrote:
> Lets see the device_move function, seems there's some problems in it:
>
> 1302 int device_move(struct device *dev, struct device *new_parent)
> 1303 {
> 1304 int error;
> 1305 struct device *old_parent;
> 1306 struct kobject *new_parent_kobj;
> 1307
> 1308 dev = get_device(dev);
> 1309 if (!dev)
> 1310 return -EINVAL;
> 1311
> 1312 new_parent = get_device(new_parent);
> 1313 new_parent_kobj = get_device_parent (dev, new_parent);
>
> Here could get kobject reference
Eww. get_device_parent() may inflate the refcount in one case
for !CONFIG_SYSFS_DEPRECATED, but often won't. (And the function is
named confusingly, since it hints that we always get a reference, which
we don't.)
>
> 1314 if (IS_ERR(new_parent_kobj)) {
> 1315 error = PTR_ERR(new_parent_kobj);
> 1316 put_device(new_parent);
> 1317 goto out;
> 1318 }
> 1319 pr_debug("DEVICE: moving '%s' to '%s'\n", dev->bus_id,
> 1320 new_parent ? new_parent->bus_id : "<NULL>");
> 1321 error = kobject_move(&dev->kobj, new_parent_kobj);
> 1322 if (error) {
> 1323 put_device(new_parent);
>
> imagine new_parent is NULL, then the new_parent_kobj should be put
No, we would need a put_device_parent() (crappy name) which puts the
reference iff get_device_parent() grabbed it.
>
> 1324 goto out;
> 1325 }
> 1326 old_parent = dev->parent;
> 1327 dev->parent = new_parent;
> 1328 if (old_parent)
> 1329 klist_remove(&dev->knode_parent);
> 1330 if (new_parent)
> 1331 klist_add_tail(&dev->knode_parent,
> &new_parent->klist_children);
> 1332 if (!dev->class)
> 1333 goto out_put;
>
> Why not put new_parent | new_parent_kobj?
Because that is the good case :)
>
> 1334 error = device_move_class_links(dev, old_parent, new_parent);
> 1335 if (error) {
> 1336 /* We ignore errors on cleanup since we're hosed
> anyway... */
> 1337 device_move_class_links(dev, new_parent, old_parent);
> 1338 if (!kobject_move(&dev->kobj, &old_parent->kobj)) {
> 1339 if (new_parent)
> 1340 klist_remove(&dev->knode_parent);
> 1341 if (old_parent)
> 1342 klist_add_tail(&dev->knode_parent,
> 1343
> &old_parent->klist_children);
> 1344 }
> 1345 put_device(new_parent);
>
> Same doubt as above
We'd need put_device_parent() or whatever here as well, I guess.
>
> 1346 goto out;
> 1347 }
> 1348 out_put:
> 1349 put_device(old_parent);
> 1350 out:
> 1351 put_device(dev);
> 1352 return error;
> 1353 }
>
> Hope I'm wrong, but if it's indeed bugs, I will send a patch about this.
There are more problems, I'm afraid :( setup_parent() calls
get_device_parent() as well, so device_add() has the same problems on
error cleanup...
I'll take a look at it if I find some time, but I'm afraid I'll not
be able to do so before next week.
next prev parent reply other threads:[~2008-01-18 9:20 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-28 17:32 Gabor Gombas
2007-12-29 8:07 ` [Bluez-devel] " Dave Young
2008-01-02 14:48 ` Gabor Gombas
2008-01-02 15:16 ` Gabor Gombas
2008-01-03 13:16 ` Gabor Gombas
2008-01-04 1:05 ` Dave Young
2008-01-07 8:07 ` Tejun Heo
2008-01-07 14:10 ` Gabor Gombas
2008-01-05 7:50 ` Al Viro
2008-01-05 14:30 ` Tejun Heo
2008-01-05 19:45 ` Al Viro
2008-01-06 2:07 ` Tejun Heo
2008-01-06 2:18 ` Al Viro
2008-01-06 2:54 ` Tejun Heo
2008-01-06 3:35 ` Al Viro
2008-01-06 3:54 ` Tejun Heo
2008-01-07 2:37 ` Tejun Heo
2008-01-07 8:21 ` Eric W. Biederman
2008-01-07 9:17 ` Tejun Heo
2008-01-07 9:18 ` Tejun Heo
2008-01-07 9:22 ` Al Viro
2008-01-07 10:33 ` Eric W. Biederman
2008-01-07 14:13 ` Gabor Gombas
2008-01-07 15:24 ` Tejun Heo
2008-01-07 21:00 ` Gabor Gombas
2008-01-08 9:42 ` Tejun Heo
2008-01-08 13:32 ` Gabor Gombas
2008-01-09 9:16 ` Tejun Heo
2008-01-09 15:57 ` Cornelia Huck
2008-01-10 1:11 ` Dave Young
2008-01-11 23:09 ` Gabor Gombas
2008-01-14 7:05 ` Dave Young
2008-01-14 12:52 ` Cornelia Huck
2008-01-15 1:57 ` Dave Young
2008-01-16 1:02 ` Dave Young
2008-01-16 23:06 ` Gabor Gombas
2008-01-17 7:24 ` Dave Young
2008-01-17 8:15 ` Dave Young
2008-01-17 11:42 ` Cornelia Huck
2008-01-18 3:37 ` Dave Young
2008-01-18 9:19 ` Cornelia Huck [this message]
2008-01-18 10:23 ` Cornelia Huck
2008-01-18 10:34 ` Dave Young
2008-01-18 11:26 ` Cornelia Huck
2008-01-21 3:15 ` Dave Young
2008-01-21 15:09 ` [Patch] Driver core: Cleanup get_device_parent() in device_add() and device_move() Cornelia Huck
2008-01-10 10:15 ` [Bluez-devel] Oops involving RFCOMM and sysfs Gabor Gombas
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=20080118101933.258bfae9@gondolin.boeblingen.de.ibm.com \
--to=cornelia.huck@de.ibm.com \
--cc=bluez-devel@lists.sourceforge.net \
--cc=davem@davemloft.net \
--cc=gombasg@sztaki.hu \
--cc=greg@kroah.com \
--cc=hidave.darkstar@gmail.com \
--cc=htejun@gmail.com \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcel@holtmann.org \
--cc=viro@zeniv.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®