From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752830AbdIAVuJ (ORCPT ); Fri, 1 Sep 2017 17:50:09 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:35143 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752519AbdIAVuI (ORCPT ); Fri, 1 Sep 2017 17:50:08 -0400 Date: Fri, 1 Sep 2017 23:50:03 +0200 From: Peter Zijlstra To: David Howells Cc: linux-afs@lists.infradead.org, linux-fsdevel@vger.kernel.org, Kees Cook , linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 02/11] refcount: Implement inc/decrement-and-return functions Message-ID: <20170901215003.GA17526@worktop.programming.kicks-ass.net> References: <20170901164233.wu4fdljpivzf5idb@hirez.programming.kicks-ass.net> <150428045304.25051.1778333106306853298.stgit@warthog.procyon.org.uk> <150428046185.25051.3518486828049323804.stgit@warthog.procyon.org.uk> <3696.1504300539@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3696.1504300539@warthog.procyon.org.uk> User-Agent: Mutt/1.5.22.1 (2013-10-16) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 01, 2017 at 10:15:39PM +0100, David Howells wrote: > Peter Zijlstra wrote: > > > > unsigned int refcount_dec_return(refcount_t *r); > > > unsigned int refcount_inc_return(refcount_t *r); > > > > > > > I'm not immediately seeing how wanting 1 to mean unused leads to > > requiring these two functions. > > Did you read the other other part of the description? > > Further, both functions can be used to accurately trace the refcount > (refcount_inc() followed by refcount_read() can't be considered > accurate). I must admit to having overlooked that. But can we treat the two issues separately? They are quite distinct. > > If you'll remember, I did that for inode_count and only needed > > dec_unless(). > > I don't remember. inode_count? I can't find such a thing - did you mean > i_count? I don't find anything matching "dec_unless.*i_count" either. Ah, yes, i_count. See these: https://lkml.kernel.org/r/20170224162044.479190330@infradead.org https://lkml.kernel.org/r/20170224162044.548813302@infradead.org But looking at them, i_count was rather special, a normal GC based scheme doesn't need anything new AFAICT: add: spin_lock(&map->lock) refcount_set(&obj->refs, 1); map_link(map, obj); spin_unlock(&map->lock); lookup: rcu_read_lock(); obj = map_find(map, key); if (obj && !refcount_inc_not_zero(&obj->refs)) obj = NULL; rcu_read_unlock(); if (obj) { /* use obj */ refcount_dec(&obj->refs); /* should never hit 0 */ } GC: spin_lock(&map->lock); map_for_each_obj_safe(obj, map) { if (refcount_dec_if_one(&obj->refs)) { map_unlink(map, obj); rcu_free(obj); } } spin_unlock(&map->lock);