lkml.org 
[lkml]   [2014]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH RFC 1/4] kactive: introduce generic "active"-refcounts
From
Hi Tejun

On Mon, Aug 18, 2014 at 11:03 PM, Tejun Heo <tj@kernel.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


\
 
 \ /
  Last update: 2014-08-19 10:41    [W:0.071 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site