lkml.org 
[lkml]   [2004]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectQuestion about (or bug in?) the kobject implementation
Is it supposed to be legal to repeatedly call kobject_add() and 
kobject_del() for the same kobject? That is, is

kobject_add(&kobj);
...
kobject_del(&kobj);
...
kobject_add(&kobj);
...
kobject_del(&kobj);

supposed to work? The API doesn't forbid it, and there's no apparent
reason why it should be illegal.

I ask because the current implementation is set up in such a way that
doing this will mess up the reference counting for the kobject's parent.
The problem is that the parent's refcount is increased each time
kobject_add() is called, but it is only decremented in kobject_cleanup(),
not in kobject_del(). Thus, the statements above will leave the parent's
refcount permanently increased by 1, potentially causing a memory leak.

Why would anyone want to do this, you ask? Well the USB subsystem does it
already. Each USB device can have several configurations, only one of
which is active at any time. Corresponding to each configuration is a set
of struct devices, and they (together with their embedded kobjects) are
allocated and initialized when the USB device is first detected. The
struct devices are add()'ed and del()'ed as configurations are activated
and deactivated, leading to just the sort of call sequence shown above.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:01    [W:0.050 / U:3.480 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site