Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp2922705rwd; Fri, 19 May 2023 12:05:08 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5tTdhIYl11RePBaPV8aIoFXW3rWSVDFZSNdwxqNRWG6gL2FsQfZr88CvfVmZpNX4FNtOSI X-Received: by 2002:a17:902:e5ce:b0:1ac:528c:e71 with SMTP id u14-20020a170902e5ce00b001ac528c0e71mr4738008plf.18.1684523107918; Fri, 19 May 2023 12:05:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684523107; cv=none; d=google.com; s=arc-20160816; b=vqd5AWndQSBcjsGgXemCSfMItkt07dIyiTH3KOBCaDUUJSdWaRCMCdPiMzs1zfiPPl vUIkPuRgShCkQUl6XEsf5HR4ggvbZp6rqHQlcXgrR4XIIcx5/0Wk/5p6He4bTtG6MuNk QAHnjkpEZfjYH/TYFKwRG796IANsXE+VvUBY7Ji0wbcf/KJmAG85zXt2puozPUvZqtJn XLeECdzvyJqZxSe/FEBlH3o1TGAG8uSlQVW2qrOdmJ/2Q3EB4zSdOyeokQHDs8s+vrqR iRF3Z5qsZrq64abWFcFhG2Qe6x6SHT2YHWRjwmBsz9JNnMuHizb4ib++pFQNy76oI3OF Gs+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=IvuKY+QiDOSLvpXbndNJuNB4TnmV65tz5O+BwirwJsE=; b=vkiN+z6pCJmGG7igXYLmxILYGKQbBe3Zm2WIYxzTh7z2OxnqpMZyznrP4bA6UdqZm+ Yp9iUBHewk5FdRN3UpAxeUaSrbz5OVnWOqc9KyIN/KeiUP3Kmy4BbNTlZ0H5jBWqCRmd 8AV2fEhWPIiqGrelqu0tniLz+zcFvFmf47Js+FNhsR3uDw7cBYC/j9LhU51RNUcmBVhq hER+6e16VlUGUhB3TMNlDeBjkMhiDROUos+FOoKu9PnP6g3rKIOECkuxOGJDFh66YkQD z7yR2e+HJdZX5dfJJs+rOo+dmE3iuVwuuAl8nb6Vj40pCz7A2fPevvXhs5V2kJkN33/n 4ORg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=cQEFC8tu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v11-20020a63b94b000000b0050fa9bc63cbsi70947pgo.432.2023.05.19.12.04.53; Fri, 19 May 2023 12:05:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=cQEFC8tu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229773AbjESSxE (ORCPT + 99 others); Fri, 19 May 2023 14:53:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47400 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229504AbjESSxD (ORCPT ); Fri, 19 May 2023 14:53:03 -0400 Received: from mail-yw1-x1133.google.com (mail-yw1-x1133.google.com [IPv6:2607:f8b0:4864:20::1133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5D869E45 for ; Fri, 19 May 2023 11:53:02 -0700 (PDT) Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-561bb2be5f8so46448157b3.0 for ; Fri, 19 May 2023 11:53:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; t=1684522381; x=1687114381; 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=IvuKY+QiDOSLvpXbndNJuNB4TnmV65tz5O+BwirwJsE=; b=cQEFC8tuad0qBhxqpwtvv0nLTlTibMvPJDQnyjusclVn14+QH4ihHQrIqRw2DEz+JK BJ0+YvvKq+psiSFOyfBxFnwWmf1LpJdJMSyEogWaGJEbHIiyCUspbIhPjVEe26EUEFeq ozsT9vTGWhambTmSQsW53Rg+POo8Tp4eyXBOY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684522381; x=1687114381; 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=IvuKY+QiDOSLvpXbndNJuNB4TnmV65tz5O+BwirwJsE=; b=Q3KIfZr+nS8uMDbFpgKc5979BtaAtGyBD3Qj14+OQzGRQdafcMquviRTybMRLgu3Yc uxm2NkpyVFazjrG6kcAKX2Y6vaZ/IudAel06RDPFbWsD+HbsO4qTw17vZbK4JntZROxT ptlTzmn2XiXNlZaVPWa5eo1zCwTe/Mxl0RsrDQvyo9NGKbrcllNDE5s6T+T7ZGErnxq4 FaZr166gtFANDgJyTbVVs7G28xapssrJ2a4B5qgbPJIaVKT7Q2BSkRLEbNNz5+C8yQMC A+eSOwXr6rpFmGPN+J4dg5GbzHaoBiIiOBjSj0N3G1SPIqc5pRKJUR2h4s3vcoTJXm/5 PnLg== X-Gm-Message-State: AC+VfDzTd0+fNdVNJz37m0v+/DPrTcJCDlPKcjgj5PftR3wSdwYK4enc yn4UlHmevNONV8/5w9EuOvMQkIVv9SW5t5b6u/LNmQ== X-Received: by 2002:a0d:d44f:0:b0:55d:aff9:975b with SMTP id w76-20020a0dd44f000000b0055daff9975bmr3126455ywd.12.1684522381325; Fri, 19 May 2023 11:53:01 -0700 (PDT) MIME-Version: 1.0 References: <20230518224008.2468-1-sj@kernel.org> <20230518224008.2468-5-sj@kernel.org> In-Reply-To: <20230518224008.2468-5-sj@kernel.org> From: Joel Fernandes Date: Fri, 19 May 2023 14:52:50 -0400 Message-ID: Subject: Re: [PATCH 4/4] Docs/RCU/rculist_nulls: Drop unnecessary '_release' in insert function To: SeongJae Park Cc: paulmck@kernel.org, corbet@lwn.net, rcu@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 18, 2023 at 6:40=E2=80=AFPM SeongJae Park wrote= : > > The document says we can avoid extra smp_rmb() in lockless_lookup() and > extra _release() in insert function when hlist_nulls is used. However, > the example code snippet for the insert function is still using the > extra _release(). Drop it. > > Signed-off-by: SeongJae Park > --- > Documentation/RCU/rculist_nulls.rst | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/RCU/rculist_nulls.rst b/Documentation/RCU/rcul= ist_nulls.rst > index 5cd6f3f8810f..463270273d89 100644 > --- a/Documentation/RCU/rculist_nulls.rst > +++ b/Documentation/RCU/rculist_nulls.rst > @@ -191,7 +191,7 @@ scan the list again without harm. > obj =3D kmem_cache_alloc(cachep); > lock_chain(); // typically a spin_lock() > obj->key =3D key; > - atomic_set_release(&obj->refcnt, 1); // key before refcnt > + atomic_set(&obj->refcnt, 1); > /* > * insert obj in RCU way (readers might be traversing chain) > */ If write to ->refcnt of 1 is reordered with setting of ->key, what prevents the 'lookup algorithm' from doing a key match (obj->key =3D=3D key) before the refcount has been initialized? Are we sure the reordering mentioned in the document is the same as the reordering prevented by the atomic_set_release()? For the other 3 patches, feel free to add: Reviewed-by: Joel Fernandes (Google) thanks, - Joel