Question about (or bug in?) the kobject implementation

[Alan Stern]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/