From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751844AbdB0JaA (ORCPT ); Mon, 27 Feb 2017 04:30:00 -0500 Received: from mga11.intel.com ([192.55.52.93]:62051 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751614AbdB0J3z (ORCPT ); Mon, 27 Feb 2017 04:29:55 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,213,1484035200"; d="scan'208";a="53337834" From: "Reshetova, Elena" To: Peter Zijlstra , Al Viro , Linus Torvalds , Chris Mason CC: "linux-kernel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "David Howells" , "ishkamiel@gmail.com" , "dwindsor@gmail.com" , "gregkh@linuxfoundation.org" Subject: RE: [RFC][PATCH 09/10] locking/refcount: Provide refcount_dec_unless() Thread-Topic: [RFC][PATCH 09/10] locking/refcount: Provide refcount_dec_unless() Thread-Index: AQHSjryLXoRkdaAphUuiWUMGGe6KKaF8ldVA Date: Mon, 27 Feb 2017 09:28:39 +0000 Message-ID: <2236FBA76BA1254E88B949DDB74E612B41C505C4@IRSMSX102.ger.corp.intel.com> References: <20170224154329.478276481@infradead.org> <20170224162044.479190330@infradead.org> In-Reply-To: <20170224162044.479190330@infradead.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v1R9U3gm002255 > By allowing a different unless value than 1, we can do dec_and_lock > like things on higher values, like 2, which is useful if the data > structure we lock also owns a reference (because in that case we'd > never hit 1). > > Signed-off-by: Peter Zijlstra (Intel) > --- > include/linux/refcount.h | 8 +++++++- > lib/refcount.c | 14 ++++++++------ > 2 files changed, 15 insertions(+), 7 deletions(-) Even if we decide not to touch inode->i_count because people believe it doesn't make that much sense, this API extension would be highly useful in other places. The consequences if an usage counter overflows can be also very much undesirable and I don't think the code that uses them is prepared to handle such cases. So we also need a way to address it if we want to get rid of problem in general. In some cases you can do a general +1 on counting scheme, benefit from an existing lock and convert them to refcount_t, but sometimes it is really not appropriate to take a new generic lock. So, there are basically two ways for converting these cases: - create a new type, usagecounter_t (put whatever name you like) (as we discussed before a number of times) and provide below functions there - extend refcount_t type to have the below functions First approach might be overall cleaner, but extend even further the set of atomic-like primitives we already have. Some people get confused when given too many choices and default to atomic_t as "old, default option". We don't want this to happen. Second approach is more compact, but its usage needs to be documented more precisely. Personally it is hard for me to think of a case when adding refcount_dec_unless() to API would result in people misusing refcount_t API more than they would do without it. But maybe I am not creative enough? Best Regards, Elena.