Date:	Tue, 19 Aug 2014 10:29:31 +0200
From:	David Herrmann <dh.herrmann@...il.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Theodore Tso <tytso@....edu>,
	Christoph Hellwig <hch@...radead.org>
Subject: Re: [PATCH RFC 1/4] kactive: introduce generic "active"-refcounts

Hi Tejun

On Mon, Aug 18, 2014 at 11:03 PM, Tejun Heo <tj@...nel.org> wrote:
> 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 have no objections to embedding it into revoke(2).

> * 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.

Yes, I saw that you just drop the own reference and then acquire a
fake-ref to simplify exit-paths. Not sure which's the better way. I
guess for the start it'd be enough to just get normal draining and add
self-draining once we're done with the base implementation.

> 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?

kernfs also requires delayed 'enable' for attributes, so you can
enable a whole tree at once. I haven't added support for this to
revoke(2), but I'm planning to.

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

Powered by blists - more mailing lists