From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail115-80.sinamail.sina.com.cn (mail115-80.sinamail.sina.com.cn [218.30.115.80]) (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 484B019539F for ; Thu, 16 Jan 2025 10:52:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=218.30.115.80 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737024782; cv=none; b=Qr7ebvO7OWFMpiaQk7jzgDisHr6yXc2jKYksid1jFclouA9s75WqvdBccxtxXPzLcnrg38xHKGzuUsVgUjIsQ1tOFiw9reNcxQkgEihtS0ZpUrDyVjC6x8DCBygOqXrx1QHTyIAuMIGs49585pF+jMHtyYjmK/TW40ZUE30qEXU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737024782; c=relaxed/simple; bh=bGSLQgo2pDJ9Hgzb2m9ztmeCcV9857iKIDnd7+5YikY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SXmeW1ny0XliVhFxDHWZfgopt5uzECyd4tMtpZ+hs/DQs2LQiwndiq/wWXEKJ3DdtJARrwYfevTO0FrIbxOfYpt9j4PxtZt0RxpOA5XAHBxREAqJ7G+AqnqYCecZoFG2bgUdOQ+G1nbrnEyeoRkOXa5hx/Su1cHh6OoI8k1JgUs= 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.80 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.66.228]) by sina.com (10.185.250.23) with ESMTP id 6788E4FD00006B88; Thu, 16 Jan 2025 18:52:48 +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: 709908913235 X-SMAIL-UIID: 81EC6948B6094F3080A5292AD3ED5E7F-20250116-185248-1 From: Hillf Danton To: Peter Zijlstra Cc: Suren Baghdasaryan , akpm@linux-foundation.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: Thu, 16 Jan 2025 18:52:35 +0800 Message-ID: <20250116105236.1916-1-hdanton@sina.com> In-Reply-To: <20250115093955.GW5388@noisy.programming.kicks-ass.net> References: <20250111042604.3230628-1-surenb@google.com> <20250111042604.3230628-11-surenb@google.com> <20250111063152.1638-1-hdanton@sina.com> <20250111121320.1656-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-Transfer-Encoding: 8bit On Wed, 15 Jan 2025 10:39:55 +0100 Peter Zijlstra > > Sigh; don't let hillf confuse you. *IF* you need an acquire it will be > in the part where you wait for readers to go away. But even there, think > about what you're serializing against. Readers don't typically modify > things. > > And modifications are fully serialized by mmap_sem^H^H^Hlock. > ^H^H^H - * Do note that inc_not_zero() provides a control dependency which will order - * future stores against the inc, this ensures we'll never modify the object - * if we did not in fact acquire a reference. + * Do note that inc_not_zero() does provide acquire order, which will order + * future load and stores against the inc, this ensures all subsequent accesses + * are from this object and not anything previously occupying this memory -- + * consider SLAB_TYPESAFE_BY_RCU. * * The decrements will provide release order, such that all the prior loads and * stores will be issued before, it also provides a control dependency, which @@ -144,7 +145,7 @@ bool __refcount_add_not_zero(int i, refcount_t *r, int *oldp) do { if (!old) break; - } while (!atomic_try_cmpxchg_relaxed(&r->refs, &old, old + i)); + } while (!atomic_try_cmpxchg_acquire(&r->refs, &old, old + i));