Hello, On Tue, Aug 12, 2014 at 08:54:05PM +0200, David Herrmann wrote: > This introduces a new reference-type "struct kactive". Unlike kref, this > type manages "active references". That means, references can only be > acquired if the object is active. At any time the object can be > deactivated, causing any new attempt to acquire an active reference to > fail. Furthermore, after disabling an object, you can wait for all active > references to be dropped. This allows synchronous object removal without > dangling _active_ objects. > > This obivously does NOT replace the usual ref-count. Moreover, it is meant > to be used in combination with normal ref-counts. This way, you can get > active references and normal references to the object. > > Active references are usually required for callbacks. That is, if an > object has callbacks that can be entered by user-space, you usually want > an active reference to the object as long as you are _inside_ the > callback. This way the object cannot be removed while you work on it. > Normal references, on the other hand, are required by the underlying > file/device to make sure the object with its callback-pointer can be > accessed at all. > > kernfs implements an active-reference type with spin-locks. This patch is > very loosely based on kernfs but avoids spin-locks. Yeah, this is very similar to kernfs's [de]activation support which is pretty much a revocation mechanism. I have two comments. * Is it necessary to make this a library? Should it just be embedded into revoke(2) implementation? * I struggled a lot with self-draining support in kernfs. Ultimately, what worked is the ability to just put the reference which is held for the current invocation, fully delegating the responsibility of keeping the current object accessible to whoever requested to put that reference. Self-draining can be implemented on top of it but that in itself is a bit too rigid for dynamic filesystems. I'd love to see this in vfs layer. A lot of kernfs's complexities come from revocation support and using something common would be nice. If this gets in, do you plan to convert kernfs to use it? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
