Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1587930

Re: [RFC][PATCH 00/10] On inode::i_count and the usage vs reference count issue

From Al Viro <viro@ZenIV.linux.org.uk>
Newsgroups linux.kernel
Subject Re: [RFC][PATCH 00/10] On inode::i_count and the usage vs reference count issue
Date 2017-02-24 21:50 +0100
Message-ID <teuYp-5wX-13@gated-at.bofh.it> (permalink)
References <tere9-2Ov-9@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Fri, Feb 24, 2017 at 04:43:29PM +0100, Peter Zijlstra wrote:
 
> There's a number of options here:
> 
>  - I'm not completely insane, and these patches can be made to work.
> 
>  - We decide usage-counts are useful and try and support them in refcount_t;
>    this has the down-side that people can more easily write bad code (by doing
>    from 0 increments that should not have happened).
> 
>  - We decide usage-counts need their own type (urgh, more...).
> 
>  - None of the above, we keep i_count as is and let people hunt and convert
>    actual refcounts.

The last one; if some object has non-trivial lifetime rules, don't try to
shoehorn it into refcount_t.  VFS-side the same goes for
struct dentry		(non-trivial lifetime and locking rules)
struct mount		(per-CPU fun, barriers, etc.)
struct super_block	(non-trivial lifecycle and lifetime rules)

I'm not sure if struct file is a good match, BTW - net/unix/garbage.c would
be one place in need of a careful looking into if we went for it.

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

[RFC][PATCH 00/10] On inode::i_count and the usage vs reference count issue Peter Zijlstra <peterz@infradead.org> - 2017-02-24 20:10 +0100
  Fwd: [RFC][PATCH 00/10] On inode::i_count and the usage vs reference  count issue Linus Torvalds <torvalds@linux-foundation.org> - 2017-02-24 20:30 +0100
  Re: [RFC][PATCH 00/10] On inode::i_count and the usage vs reference  count issue Al Viro <viro@ZenIV.linux.org.uk> - 2017-02-24 21:50 +0100

csiph-web