Message ID | 20230613182434.88317-4-sj@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp767731vqr; Tue, 13 Jun 2023 12:08:31 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6O5I5CJSfzdoAnq2HwmhrWY7OE4Hu2vz9jEtIGdr653OPyZQlNEikb6vHqJyt+728kYboh X-Received: by 2002:a17:906:da82:b0:979:7624:1f71 with SMTP id xh2-20020a170906da8200b0097976241f71mr12117357ejb.26.1686683310845; Tue, 13 Jun 2023 12:08:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686683310; cv=none; d=google.com; s=arc-20160816; b=NZgr9xqyAwYljJ3hQqRW9YMDIqVboeNQ0SBTND32aSC2ImhEXjEW4d4M32+foZTcsK 7XmkSEbtFYmEuwb2BNqMea+u2Or7TnqR8UJDmrMXC4rrkjs8Y4D/5xuoW4jwKkTitGJv NlR9u8IF0Ojqmvj+jdKZVgBGNIl6+EZUkD5lQwvuORVGo+cDfygOP3zZgERg/cL3+rDw LoXWOt5k7RPglpnViqt5/Fl+yVaRFULPUqpeE9OOo51HtsJQOKzY/Au/GJGV8DdFPlEW dNhM/kYSiqOBXavJVCsR9Wgs+d1f9BKh9ZrLKLJtNfSg2ZT/U3nwHwWjxraYUkKCTijx BU3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=ulfwIl/z03ZpRLXacLDn8cP9Nlwi1O95dPCEm3jGDuQ=; b=smmE6l1/hSboXQ+rce/IOcpN6Wg2fxdq6XaGy5eV8KbciydEGVlcNs5xtYmzA7Ri1I uQhh8SAxWYpTV5y08v+luD1pKE8iNC3+rIut4L1CZQzMxFBxA+ltMkqcCqwhFaOisd4d d0ssJxfOStaAClt3B3ZsrPrM1QBl0to5oA2/Ui5+Ghs4JL4OkzBNvc3KYVt6QLU50VLA qJXwRaoZT7ElkaHnA8lpzpAkP2U5wJZv6yrj2q2+uVINIZCuYhvS6nzYEQy8g168rV7m SigHf1I17s9n0HMckRDAaEXRIOi2C6Rmdbl9aJsrbj5HPUMM+efl8+AcVrBLt6uZaBsN XkXQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=MqD8aL5x; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gx21-20020a170906f1d500b0096f8928ed7fsi7244436ejb.254.2023.06.13.12.08.05; Tue, 13 Jun 2023 12:08:30 -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=@kernel.org header.s=k20201202 header.b=MqD8aL5x; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240540AbjFMSZX (ORCPT <rfc822;lekhanya01809@gmail.com> + 99 others); Tue, 13 Jun 2023 14:25:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58546 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239464AbjFMSYo (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 13 Jun 2023 14:24:44 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 09A761709; Tue, 13 Jun 2023 11:24:43 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6530E62F60; Tue, 13 Jun 2023 18:24:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4C47EC433D9; Tue, 13 Jun 2023 18:24:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686680680; bh=WK1M1XZ0REtusB+Bs/9PHEmAd7saEbfCwi8rA6lQtaw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MqD8aL5xO0CWMpkkeYW/yEn/4+ZWMtrDpJOPYc0AU818+2mltncssD4pRjLE2v/YE ul1fEqAlvphMYolgDGG9dNXMwTwv+yb6uyT1Jpv7xjDUnrbI3hMNu7NGhviBtdiQl8 eiWkvTmmoNciGcnP3TqkTDEujMewqkeFRiVq+yVsPLkHT7DCokzG9BA8GNHMjIwNH0 SE93O2hrvohcQJ499bLwlKsUGX6e/bFGvSJqT8kXNWjMJNS6rFJrrraKh+Z9noaoPD P4+JcxyVTpuuiTC4hdmAoXL9K4eJOSQt17S27ncIO6i6z1VPi/hIsT8QPEtN5H5o5c aqWzq9WFhO91g== From: SeongJae Park <sj@kernel.org> To: paulmck@kernel.org Cc: SeongJae Park <sj@kernel.org>, joel@joelfernandes.org, mmpgouride@gmail.com, corbet@lwn.net, rcu@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 3/4] Docs/RCU/rculist_nulls: Fix hlist_head field name of 'obj' Date: Tue, 13 Jun 2023 18:24:33 +0000 Message-Id: <20230613182434.88317-4-sj@kernel.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20230613182434.88317-1-sj@kernel.org> References: <20230613182434.88317-1-sj@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1768615639606068770?= X-GMAIL-MSGID: =?utf-8?q?1768615639606068770?= |
Series |
Docs/RCU/rculist_nulls: Minor fixups
|
|
Commit Message
SeongJae Park
June 13, 2023, 6:24 p.m. UTC
The example code snippets on rculist_nulls.rst are assuming 'obj' to have the 'hlist_head' field named 'obj_node', but a sentence is wrongly mentioning 'obj->obj_node.next' as 'obj->obj_next'. Fix it. Signed-off-by: SeongJae Park <sj@kernel.org> Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org> --- Documentation/RCU/rculist_nulls.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Tue, Jun 13, 2023 at 06:24:33PM +0000, SeongJae Park wrote: > The example code snippets on rculist_nulls.rst are assuming 'obj' to > have the 'hlist_head' field named 'obj_node', but a sentence is wrongly > mentioning 'obj->obj_node.next' as 'obj->obj_next'. Fix it. > > Signed-off-by: SeongJae Park <sj@kernel.org> > Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org> > --- > Documentation/RCU/rculist_nulls.rst | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/RCU/rculist_nulls.rst b/Documentation/RCU/rculist_nulls.rst > index 94a8bfe9f560..5cd6f3f8810f 100644 > --- a/Documentation/RCU/rculist_nulls.rst > +++ b/Documentation/RCU/rculist_nulls.rst > @@ -86,7 +86,7 @@ Quoting Corey Minyard:: > 2) Insertion algorithm > ---------------------- > > -We need to make sure a reader cannot read the new 'obj->obj_next' value > +We need to make sure a reader cannot read the new 'obj->obj_node.next' value I do like this being more specific, but if we are going do add this level of specificity, shouldn't we refer to a definition of ->obj_node? (I queued and pushed 1/4 and 2/4, thank you, and stopped here.) Thanx, Paul > and previous value of 'obj->key'. Otherwise, an item could be deleted > from a chain, and inserted into another chain. If new chain was empty > before the move, 'next' pointer is NULL, and lockless reader can not > -- > 2.25.1 >
On Wed, 14 Jun 2023 09:36:50 -0700 "Paul E. McKenney" <paulmck@kernel.org> wrote: > On Tue, Jun 13, 2023 at 06:24:33PM +0000, SeongJae Park wrote: > > The example code snippets on rculist_nulls.rst are assuming 'obj' to > > have the 'hlist_head' field named 'obj_node', but a sentence is wrongly > > mentioning 'obj->obj_node.next' as 'obj->obj_next'. Fix it. > > > > Signed-off-by: SeongJae Park <sj@kernel.org> > > Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org> > > --- > > Documentation/RCU/rculist_nulls.rst | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/Documentation/RCU/rculist_nulls.rst b/Documentation/RCU/rculist_nulls.rst > > index 94a8bfe9f560..5cd6f3f8810f 100644 > > --- a/Documentation/RCU/rculist_nulls.rst > > +++ b/Documentation/RCU/rculist_nulls.rst > > @@ -86,7 +86,7 @@ Quoting Corey Minyard:: > > 2) Insertion algorithm > > ---------------------- > > > > -We need to make sure a reader cannot read the new 'obj->obj_next' value > > +We need to make sure a reader cannot read the new 'obj->obj_node.next' value > > I do like this being more specific, but if we are going do add this > level of specificity, shouldn't we refer to a definition of ->obj_node? Agreed, I will add the example definition in the next spin. I also found we would better to further fix wrong 'member' field assumption, like below: - ({ obj = hlist_entry(pos, typeof(*obj), member); 1; }); + ({ obj = hlist_entry(pos, typeof(*obj), obj_node); 1; }); Thanks, SJ > > (I queued and pushed 1/4 and 2/4, thank you, and stopped here.) > > Thanx, Paul > > > and previous value of 'obj->key'. Otherwise, an item could be deleted > > from a chain, and inserted into another chain. If new chain was empty > > before the move, 'next' pointer is NULL, and lockless reader can not > > -- > > 2.25.1 > > >
diff --git a/Documentation/RCU/rculist_nulls.rst b/Documentation/RCU/rculist_nulls.rst index 94a8bfe9f560..5cd6f3f8810f 100644 --- a/Documentation/RCU/rculist_nulls.rst +++ b/Documentation/RCU/rculist_nulls.rst @@ -86,7 +86,7 @@ Quoting Corey Minyard:: 2) Insertion algorithm ---------------------- -We need to make sure a reader cannot read the new 'obj->obj_next' value +We need to make sure a reader cannot read the new 'obj->obj_node.next' value and previous value of 'obj->key'. Otherwise, an item could be deleted from a chain, and inserted into another chain. If new chain was empty before the move, 'next' pointer is NULL, and lockless reader can not