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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEXv5_hVfyFkEAKBjvgku-oskbGhsB_daDEinZJeSvtP6tm0gg@mail.gmail.com>
Date:   Fri, 24 Feb 2017 15:59:01 -0500
From:   David Windsor <dwindsor@...il.com>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Chris Mason <clm@...com>, LKML <linux-kernel@...r.kernel.org>,
        linux-fsdevel@...r.kernel.org, David Howells <dhowells@...hat.com>,
        "Reshetova, Elena" <elena.reshetova@...el.com>,
        Hans Liljestrand <ishkamiel@...il.com>,
        Greg KH <gregkh@...uxfoundation.org>
Subject: Re: [RFC][PATCH 00/10] On inode::i_count and the usage vs reference
 count issue

On Fri, Feb 24, 2017 at 11:43 AM, Christoph Hellwig <hch@...radead.org> wrote:
> Usage counts are common and useful, so for now they should stay as-is
> and if people can came up with a useful primitive for them we can
> consider implementing it.
>

While developing the refcount_t API, we used coccinelle to find areas
where converted atomic_t->refcount_t variables were being initialized
to 0 (rather than 1).

If we're considering a usagecount_t type, this may be a good starting
point for determining just how pervasive usage counts actually are (at
least the ones that we've converted [or attempted to convert] to
refcount_t).  Usage count types not atomic_t before the refcount_t
conversion obviously weren't included in our search.

Note that some of these have already been converted to refcounts,
either by adding a +1 bias, or some other workaround.  Others are
simply too confusing and we haven't decided what to do with them yet;
I've marked these as (not converted to refcount_t) below.

Some preemptive flame retardant: I realize that not all of these are
"usage" counts.  They _do_ all fall into the category of refcount_t
(formerly atomic_t) variables that are initialized to 0, a common
usage count idiom.  This is the same thing that's going on with struct
inode.i_count and therefore relevant to this discussion.

Not (yet) converted to refcount_t:
fs/nfsd/state.c: struct nfsd4_session.se_ref
fs/nfsd/state.c: struct nfsd4_client.cl_refcount
fs/hfsplus/hfsplus_fs.h: struct hfsplus_inode_info.opencnt
fs/xfs/xfs_log_priv.h: struct xlog_in_core.ic_refcnt
sound/usb/usbaudio.h: struct snd_usb_audio.usage_count
tools/perf/util/evlist.h: struct perf_mmap.refcnt
include/net/nf_conntrack.h: struct nf_conntrack.use
include/net/ip_vs.h: struct ip_vs_service.refcnt

Converted to refcount_t:
fs/fuse/fuse_i.h: struct fuse_file.count
fs/btrfs/delayed-inode.h: struct btrfs_delayed_inode.refs
fs/btrfs/compression.c: struct compressed_bio.pending_bios
fs/btrfs/extent_io.h: struct extent_buffer.io_pages
net/packet/internal.h: struct packet_fanout.sk_ref
xfs/xfs_buf.h: struct xfs_buf.b_lru_ref
sound/core/seq/seq_ports.h: snd_seq_subscribers.ref_count
tools/perf/util/comm.c: struct comm_str.refcnt
include/net/bluetooth/hci_core.h: struct hci_conn.refcnt
include/linux/filter.h: struct sk_filter.refcnt
include/linux/skbuff.h struct sk_buff.users

There are 7 more instances in drivers/, 3 of which haven't (yet) been
converted to refcount_t, but I'm too lazy to continue with this list.

> Trying to shoe-horn everything into refcount_t is a horrible idea.