From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail78-58.sinamail.sina.com.cn (mail78-58.sinamail.sina.com.cn [219.142.78.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 25CF529A2 for ; Sat, 11 Jan 2025 12:13:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=219.142.78.58 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736597627; cv=none; b=s9Zf9Z25yhj/xLYyHTFewlivKdDIy31lI+vxJSrgZJOlKnZeZq3pO74LpVj4TZqiUSFTxG0vci3J5/9Cfym8+g+1CwXKa+Zlf+rIQMMsQBPTipY67jm3RPBidLQs6HlynXkGkh5OQ98p3YTWeXXDXiZj7NGmb97W9KyjK35O9pk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736597627; c=relaxed/simple; bh=nKyvk3Ie+5grVPDvsIW7Ki98lnu3N0aSPjnjhyf0OKQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ZuC2yg6+vQC05z65fkzMD+60amWMdruldNm8vDP8CRh5ILMLeIw40aypEv1G0ad2jlv3mh3ZYQgIowFwKS133vzl8CjAqA92rqLcomRWe+y7T5o03ty95MAHBjwIZUZrqiL42ohpHb701lxh5Rq8MOCGBXytrIc2hcRlBt236BA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=sina.com; spf=pass smtp.mailfrom=sina.com; arc=none smtp.client-ip=219.142.78.58 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=sina.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sina.com X-SMAIL-HELO: localhost.localdomain Received: from unknown (HELO localhost.localdomain)([113.118.71.135]) by sina.com (10.185.250.24) with ESMTP id 6782606A00004DAB; Sat, 11 Jan 2025 20:13:32 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com Authentication-Results: sina.com; spf=none smtp.mailfrom=hdanton@sina.com; dkim=none header.i=none; dmarc=none action=none header.from=hdanton@sina.com X-SMAIL-MID: 54552710748401 X-SMAIL-UIID: 3491548A1AD94689BFB8E65143949F1B-20250111-201332-1 From: Hillf Danton To: Suren Baghdasaryan Cc: akpm@linux-foundation.org, peterz@infradead.org, willy@infradead.org, hannes@cmpxchg.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH v9 10/17] refcount: introduce __refcount_{add|inc}_not_zero_limited Date: Sat, 11 Jan 2025 20:13:18 +0800 Message-ID: <20250111121320.1656-1-hdanton@sina.com> In-Reply-To: References: <20250111042604.3230628-1-surenb@google.com> <20250111042604.3230628-11-surenb@google.com> <20250111063152.1638-1-hdanton@sina.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Sat, 11 Jan 2025 01:59:41 -0800 Suren Baghdasaryan > On Fri, Jan 10, 2025 at 10:32 PM Hillf Danton wrote: > > On Fri, 10 Jan 2025 20:25:57 -0800 Suren Baghdasaryan > > > -bool __refcount_add_not_zero(int i, refcount_t *r, int *oldp) > > > +bool __refcount_add_not_zero_limited(int i, refcount_t *r, int *oldp, > > > + int limit) > > > { > > > int old = refcount_read(r); > > > > > > do { > > > if (!old) > > > break; > > > + > > > + if (statically_true(limit == INT_MAX)) > > > + continue; > > > + > > > + if (i > limit - old) { > > > + if (oldp) > > > + *oldp = old; > > > + return false; > > > + } > > > } while (!atomic_try_cmpxchg_relaxed(&r->refs, &old, old + i)); > > > > The acquire version should be used, see atomic_long_try_cmpxchg_acquire() > > in kernel/locking/rwsem.c. > > This is how __refcount_add_not_zero() is already implemented and I'm > only adding support for a limit. If you think it's implemented wrong > then IMHO it should be fixed separately. > Two different things - refcount has nothing to do with locking at the first place, while what you are adding to the mm directory is something that replaces rwsem, so from the locking POV you have to mark the boundaries of the locking section.