[RFC] Potential kobject functionality (two stage delete, single delete)

[Kent Overstreet <kent.overstreet@gmail.com>]

I've been working on reference counting in my own code, and it seemed to 
me that some of this stuff would be best added to the generic code - I 
can't be the only one who's needed to solve these particular problems. 
But kobjects aren't new, maybe someone knows if any of this has been 
tried before?

The easy one would be a flag marking an object as deleted when there's 
still references. The idea is if you've got multiple unserialized ways 
of closing/deleting something - error handling paths and/or a way for a 
user to request that it be closed - you need to make sure you drop only 
one reference.

This is trivial to handle without adding to the kobject code, but it 
seems to me it ought to be common enough to warrant adding it - I 
wouldn't be surprised if there's driver code that doesn't handle it 
correctly, it's easy enough to miss if you don't think about the 
particular case. We need to add an atomic bitflag to struct kobject; 
another callback in struct kobj_type might be useful too. Then something 
like the following should be it:

void kobject_delete(struct kobject *k)
{
	if (!test_and_set_bit(deleted)) {
		if (delete_fn)
			delete_fn(k);
		kobject_put(k);
	}
}

The more annoying one is two stage delete. Unless my google-fu has 
failed me, I don't see a reasonable way of using kobject refcounting if 
you need to drop a refcount from atomic context. Without modifying the 
kobject code, I'd have to have a second refcount and combined with RCU 
things become an unreadable mess of callbacks.

I think all that would be needed would be to add a flag to kobj_type 
indicating that the release function will call kobject_cleanup; the 
release function would then be free to punt to a workqueue.

The only potential problem I see is that either the code to remove a 
kobject from sysfs has to be made safe for atomic context, or you'd have 
dead kobjects sitting in sysfs an arbitrary amount of time - it looks 
like if this was a real issue it would be with the current code too 
though, if a callback for an attribute could take a reference to a kobject.

Comments? I'll work up some patches if no one convinces me either idea's 
insane.