From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail115-24.sinamail.sina.com.cn (mail115-24.sinamail.sina.com.cn [218.30.115.24])
	(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 152FD15B980
	for <linux-kernel@vger.kernel.org>; Sat, 11 Jan 2025 06:32:12 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=218.30.115.24
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1736577138; cv=none; b=aQziS9WxVzCJowaS/bnx92OY1VkVop0oWChEFK1AbFUKKgyIQbYXv3GxQrxPb8/wpdFlMVJYUOc2gBmIbZhYOmnK6LctLEAb+PaMDKLT4hyyybaeppw+NdfqrknyiQ2cVk+78PD3rbWzRQwc/XbJc06xzR8V1FD7RVh8EQL/UWk=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1736577138; c=relaxed/simple;
	bh=i+GMkKtDd8QuEghiETa0WQPJHH6cgB7x3DdEwy0HsAg=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version; b=Ez1AZmiKf811oNQuRLjELikMJ0hyWi9MNPH+Rk0ms9cBA9W/U6C8OnIVbp9C6DFVQ57S48/HPuki6tjXtmWmRtQUKlzGoBlyyoU+iBbz+gMQP08gXx7zbWGrnQgflgIxbj5H8HnlFPrcCiGV/tZXj/flLk6SA7WHQ8Pf4S2mcfQ=
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=218.30.115.24
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.22) with ESMTP
	id 67821062000050DC; Sat, 11 Jan 2025 14:32:04 +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: 9460547602767
X-SMAIL-UIID: DB3CA4E98B2C490FAED46474773FD411-20250111-143204-1
From: Hillf Danton <hdanton@sina.com>
To: Suren Baghdasaryan <surenb@google.com>
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 14:31:49 +0800
Message-ID: <20250111063152.1638-1-hdanton@sina.com>
In-Reply-To: <20250111042604.3230628-11-surenb@google.com>
References: <20250111042604.3230628-1-surenb@google.com>
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

On Fri, 10 Jan 2025 20:25:57 -0800 Suren Baghdasaryan <surenb@google.com>
> -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.

Why not use the atomic_long_t without bothering to add this limited version?