From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 15F6FC02183 for ; Thu, 16 Jan 2025 15:12:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4E7166B0082; Thu, 16 Jan 2025 10:12:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 470106B0083; Thu, 16 Jan 2025 10:12:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2E9A56B0085; Thu, 16 Jan 2025 10:12:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 0F5236B0082 for ; Thu, 16 Jan 2025 10:12:28 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id A3002C0E01 for ; Thu, 16 Jan 2025 15:12:27 +0000 (UTC) X-FDA: 83013656334.15.0F0A42D Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by imf09.hostedemail.com (Postfix) with ESMTP id A1FAB140014 for ; Thu, 16 Jan 2025 15:12:25 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Emyg3XP4; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of surenb@google.com designates 209.85.160.176 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737040345; a=rsa-sha256; cv=none; b=APVD2xoz8JS/NtbJ8po0vTdPyzD24zBCg9Vvj9xBJMkKBLgJhi3Iuk30TOTXgmGoaremqu wBQ2ZB4M9ATF6Uu4w45yFhi6NE1/OWtUvdfIjGX3gjpuRF82Dy28FKDcN2Mop8zwYxwqy5 EcrRkVmAqY5pNKIkmLJtqASCN55Eu34= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Emyg3XP4; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.hostedemail.com: domain of surenb@google.com designates 209.85.160.176 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737040345; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=+n0nLBWn98kJwyuHw9dnciSZynzrVaqoianwsxEC3Eg=; b=sm2arfvRveqpVGIpM1ZyL0O6Z8TgjAkvUDZt5cFv2gUIrNRvgrt5Mqq9mCocEhv4WHJ4a4 MVNYIxwkiBM0DMFYbQph2Rokpx6rLnDaHSJtg5imXWpkr3u7rLcOrJuBHHKN5D9hKJQWKm 5XH2JTyweRqO3kfcUT5yVKmyseg1cdU= Received: by mail-qt1-f176.google.com with SMTP id d75a77b69052e-467abce2ef9so247221cf.0 for ; Thu, 16 Jan 2025 07:12:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1737040345; x=1737645145; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=+n0nLBWn98kJwyuHw9dnciSZynzrVaqoianwsxEC3Eg=; b=Emyg3XP47IfDxaXlaY5bS+vjHIPY5jTojTr+7JsWVCuj/9IHNk9tmt9q/cfPMEyZ/W YOG1yqnhgByVF+0/eMMrI5nMBD1arAs/w5gusw8JdPwa6JH+JpyA11EN9q1ljf1jZr2/ c5fMvkqGhGQ4TKVRvlP63Mo2OuihTF3++LNN2uSaQtCvTPZQ9DTfQrsrvkftfxYiB1lX EHTAkmkq2w3jj7HItyODdFZGD1Q1aOPcT4o8un1/PYFGIfLZLdBXHVY4XMkF1inWBU+C 4Kr3kKrM0AvIlUGMujDrxlwkpm0VdO4Rjnnc0/f14BDw6zboSRYQjDMgiYdaJj6TenoN n4+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737040345; x=1737645145; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+n0nLBWn98kJwyuHw9dnciSZynzrVaqoianwsxEC3Eg=; b=XPQtrXiSzH1sLmd3sFhpUR1RCcz8cfH//JUdgtiBNcuuIvoZCIlznOHzq1GjaMnoWn aAAftILckT+44aKO5YG/Xfi66SIPmetkC+F7OuVeRpRhtjEx6qNm9toFYduevwmyT1S/ 3aLLNGxtvRvQcr+hmqftbtF/NSxOJnT0ZWL7QwJBA1khL91T4TnNApTjb8qNZgvQSir4 DNg9LYy2Ha0HljW2oEY86TvTP5oTwqTRG5yhbzI1CetXFzDDp4Pw0n8lk7cbSWV9NJTL ePGwmt/Buw2/y1/xW0++NxkAxQ0ZCXdSOjYmewSGbkrNq4z0hh0t+EGTOwyFGprQ6X3q KQ5A== X-Forwarded-Encrypted: i=1; AJvYcCVh5yPr9ZbBvl4cj1wOaqV3UdD3t3d9TgWMelD2WVJKpv/Uh2lGrm/Ng/nlwTsHxzuRFSwShHNGMQ==@kvack.org X-Gm-Message-State: AOJu0YxoAeIUzktSZwTVGeIb0ji0MGIEYDx30gFCk3cO82tv8QsfPG/C koq4fK69ZVGiHjVGlA7pOtY+JB30UAPZAD/O/bVRQgaaxUY/wH2tUblv0mTyJ2+lmsBIydt87dF EmmV1uZ983K6tQn+KK39qrrGwREOiOllK1/7H X-Gm-Gg: ASbGncuEF43NbEmTFVeP3OIrpLHysA5Jaj5k6Lta1D1JN0F0qERZJgzGJ9tVipUBEdi xq0V/HbacsygRVrc5stx7qsRTgkSTx75AyEqUop26FDLUEpEusoYCMSIJPGR8awhS3LQ= X-Google-Smtp-Source: AGHT+IG+O/DVRwFu6EvuSaxS73MdcDHVMcicb46JgTFoFOl8iILCGYiVT+ctNM6O1o9CXO+Stlr+AjBd+/+DGsBuuGY= X-Received: by 2002:a05:622a:11cc:b0:46c:9f17:12f6 with SMTP id d75a77b69052e-46e054f0636mr3327701cf.27.1737040344411; Thu, 16 Jan 2025 07:12:24 -0800 (PST) MIME-Version: 1.0 References: <20250111042604.3230628-1-surenb@google.com> <20250111042604.3230628-12-surenb@google.com> <20250115104841.GX5388@noisy.programming.kicks-ass.net> <20250115111334.GE8385@noisy.programming.kicks-ass.net> <20250115160011.GG8385@noisy.programming.kicks-ass.net> In-Reply-To: <20250115160011.GG8385@noisy.programming.kicks-ass.net> From: Suren Baghdasaryan Date: Thu, 16 Jan 2025 07:12:13 -0800 X-Gm-Features: AbW1kvaoaeyJPp721yShu4wYM4LOzIoOGeL34SC30h8Ck__Aj0E6qb5Ke2kCGuM Message-ID: Subject: Re: [PATCH] refcount: Strengthen inc_not_zero() To: Peter Zijlstra Cc: will@kernel.org, boqun.feng@gmail.com, mark.rutland@arm.com, Mateusz Guzik , akpm@linux-foundation.org, willy@infradead.org, liam.howlett@oracle.com, lorenzo.stoakes@oracle.com, david.laight.linux@gmail.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, oliver.sang@intel.com, mgorman@techsingularity.net, david@redhat.com, peterx@redhat.com, oleg@redhat.com, dave@stgolabs.net, paulmck@kernel.org, brauner@kernel.org, dhowells@redhat.com, hdanton@sina.com, hughd@google.com, lokeshgidra@google.com, minchan@google.com, jannh@google.com, shakeel.butt@linux.dev, souravpanda@google.com, pasha.tatashin@soleen.com, klarasmodin@gmail.com, richard.weiyang@gmail.com, corbet@lwn.net, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: A1FAB140014 X-Stat-Signature: poji1f431e6h1thdpb6j7ypqzsesxzmm X-Rspam-User: X-HE-Tag: 1737040345-613740 X-HE-Meta: U2FsdGVkX1/MCziT9Vb5WueT+va6c8G0I0T8rv/NRWFA1L3CWrSzYo7QO3jwar17I0E5Ad3O1iTBTel3ZOeD+iGnn8et8j70GYCgf19y3kg5+dSeK3GJPLZsuAGLdr3z3tjUK6VRzuBPzu8Y2FcAXHFhAp5LjWrXUmYiJCa7DCs09rp+tVMA4f/9XerrFnmoydCQb9HgjcfgVHY2TMvBi0t+rhm8HULyKiFrOUeIHNTfnT85+0BM/XZXwsLX4yA+X4ria5s0q9kaav3pGA/nTELSKHo/4Db2Q+TTXE70a83HDB+WyAzvx9l4L0FVN4OcRpR5xy885Zj2rpCfNj5pUrkft8g0qwnBRy3C0WkfhwtdKK0CulHpWncMB3o+AQ83EwQiFsfGoCnxcr85gSkuy4i1AKNKTgiNtjRVOT3vGXBEk/kyt1fX+OyJZJhEeFdQl+BQxLcod70rP04GKx3229u0DTMmuin6atiEXCRkWaLUX0gLRttdr8FTks+sxPFOARFSdj/Pd3al5ldP4vXsTmiRpyTZQ7U0d/MmqYXuf3cFVaEfJn9DMjv6qYoQ5rb3BbalVXXGPaek2UvKqWl284YfLWGCffUrfc/UsyDdemoPUxhYqIvFVm/nqrbOenM/ze1ZJF36qz/D63jK1xJvWhI7jfalYJZGOJ1MX9/GSYMIADFX37Opm2LdRSGABzksnkvKqY0cHnhgo5s4IF3jTWhBw9Dh8Tt8ke18fj+RqSEgIEinpxngthGzTjKZnETTNMQc9uIGMJYy2YIOveFiK6oSsrDtb+/Pn/OOp4IOQQVkWeQT9WWdgrmkCXM6rrv2GHHHp7Ox59dHRlkloT5KFeR0ZUJbQxIh+IPN8lOfilmxgM74JidUPSb2IKv563IxvHQOw1LGg7jCEnHcwcqHlsSBXF/lPQnglhMRgwAR/xqgVgemq/mm8erd1joPyDpRDVYpZ/gafCay4FElcsd lVnT+97h cBmTHkfeNdOxmdC+GplaLg0fjSW5GPsMUAQjwammnIhPFe7Zh9uCxMgdOjYiUng2Pl6FoanDTgqYym6PTF2MlAj08+PJFdUTPBiHNbOBl9EM9tq1pmquenEDYgUbrQWrxR1oSnF5ay3zvKAvGNWqs4IULq2KWS7PpdxEKprT5AbFYMBdME09Sw+rEFDHIjXWv3GXZERu2a4hBeoMXRpLoIykNv6FSwh9Pu1zXNGencFmv1r8SXnqNWNHz3ZOctyVRQb1hz+yak3K4Y5NRe1KxKpbzVuyw+TIBJ7hX1Fi4LeOpRd8zYFTQaliZGjgq8m53IphrBDTWJjcZsV+cg4i7hq5c4yjFBhQhKGdav00HXuflOw23NQ039IBmGg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Jan 15, 2025 at 8:00=E2=80=AFAM Peter Zijlstra wrote: > > On Wed, Jan 15, 2025 at 12:13:34PM +0100, Peter Zijlstra wrote: > > > Notably, it means refcount_t is entirely unsuitable for anything > > SLAB_TYPESAFE_BY_RCU, since they all will need secondary validation > > conditions after the refcount succeeds. > > > > And this is probably fine, but let me ponder this all a little more. > > Even though SLAB_TYPESAFE_BY_RCU is relatively rare, I think we'd better > fix this, these things are hard enough as they are. > > Will, others, wdyt? I'll wait for the verdict on this patch before proceeding with my series. It obviously simplifies my job. Thanks Peter! > > --- > Subject: refcount: Strengthen inc_not_zero() > > For speculative lookups where a successful inc_not_zero() pins the > object, but where we still need to double check if the object acquired > is indeed the one we set out to aquire, needs this validation to happen > *after* the increment. > > Notably SLAB_TYPESAFE_BY_RCU is one such an example. > > Signed-off-by: Peter Zijlstra (Intel) > --- > include/linux/refcount.h | 15 ++++++++------- > 1 file changed, 8 insertions(+), 7 deletions(-) > > diff --git a/include/linux/refcount.h b/include/linux/refcount.h > index 35f039ecb272..340e7ffa445e 100644 > --- a/include/linux/refcount.h > +++ b/include/linux/refcount.h > @@ -69,9 +69,10 @@ > * its the lock acquire, for RCU/lockless data structures its the depend= ent > * load. > * > - * 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 ob= ject > - * if we did not in fact acquire a reference. > + * Do note that inc_not_zero() does provide acquire order, which will or= der > + * future load and stores against the inc, this ensures all subsequent a= ccesses > + * are from this object and not anything previously occupying this memor= y -- > + * consider SLAB_TYPESAFE_BY_RCU. > * > * The decrements will provide release order, such that all the prior lo= ads 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, in= t *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)); > > if (oldp) > *oldp =3D old; > @@ -225,9 +226,9 @@ static inline __must_check bool __refcount_inc_not_ze= ro(refcount_t *r, int *oldp > * Similar to atomic_inc_not_zero(), but will saturate at REFCOUNT_SATUR= ATED > * and WARN. > * > - * Provides no memory ordering, it is assumed the caller has guaranteed = the > - * object memory to be stable (RCU, etc.). It does provide a control dep= endency > - * and thereby orders future stores. See the comment on top. > + * Provides acquire ordering, such that subsequent accesses are after th= e > + * increment. This is important for the cases where secondary validation= is > + * required, eg. SLAB_TYPESAFE_BY_RCU. > * > * Return: true if the increment was successful, false otherwise > */