Message ID | 20231010115921.988766-24-frederic@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp141508vqb; Tue, 10 Oct 2023 05:02:21 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGJSuzgvas8+Ks0XEyKCHyvx96Uf6OUn2jVhHdlnSdOuhCGjuk9FcJwM9MU6BI5HMqQ4zTI X-Received: by 2002:a05:6a20:dd9a:b0:167:af7d:9e8c with SMTP id kw26-20020a056a20dd9a00b00167af7d9e8cmr11374534pzb.56.1696939340766; Tue, 10 Oct 2023 05:02:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696939340; cv=none; d=google.com; s=arc-20160816; b=xLqAl/2bmkEEHr75QjBHCC81J1+lbaWVpcqU9okGCgMq9Hr4K+Jossd3uYe6TJwnC+ niMuEm6twg/K8D1xgnStG+DDSupBzxz1x/YfFHvwRj3hR1y+oxzPaciys4wK7HiFyIa8 aRYYErapNXz01EPXDyTKegTYxCiVHGHOigecTudD7b7txhZ4GKql4DOreglT1sNWC5et Uf0G1CuO4s1BRzrlJ6LB/ZCZoj1YWEZsoUKN9j9tKU4gmTJHTKKsW1bevsbZoIM+snrs sUwnQqIe+rQ0ZcWAr4tFxriTcnGRaqTaVJaJegAvRPAERWmZIDxZOZQUMhueL2wiXBFK o3qQ== 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=yD83G4ectQwwXXmlG7UYsW94ISGfL2Bvbl/krVDfQv8=; fh=STt8ARl3+MaHAPfeTw5U30HTakllX6RPNp8PMB4dgwE=; b=nmCcNJahVlLQzVZu29b0wx0O3Xr9ZTJStLL/nmbiv6M17RV6k+Se37TpUGPCOmWRUR 1PGAsprNTreVRGzHFjIW19kN+zXMXVJUr+cnRIktgjC2JJ3EwoFd89Ew/kXxwDSVYg7e OwHHn/7/+pTfztMuKZHl5h9JmU2AInOxpXhmHWUzPHbLMkAbbQASzKv39HDudlyI/8Rp 1KbFgYcRztU0UmaCgIedeZqiIQlwceKXl2HqsHmBdu5eDBl/Fe8DTlhpotTs8003ZlRV 7xTly2b/Q4DTC71ghx9eucxoDSNeRDjxPgRp7OJ+hys/cNiPzDTUet83VpCNclu2CZml TqFA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=NQofG2QV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 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 agentk.vger.email (agentk.vger.email. [23.128.96.32]) by mx.google.com with ESMTPS id e7-20020a62ee07000000b0068fa57d2442si8879751pfi.130.2023.10.10.05.02.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Oct 2023 05:02:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=NQofG2QV; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 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 (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id CEB4D801CFCE; Tue, 10 Oct 2023 05:02:18 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231966AbjJJMB7 (ORCPT <rfc822;rua109.linux@gmail.com> + 20 others); Tue, 10 Oct 2023 08:01:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46118 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231908AbjJJMBP (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 10 Oct 2023 08:01:15 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0971318F; Tue, 10 Oct 2023 05:00:38 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 24D99C433CC; Tue, 10 Oct 2023 12:00:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1696939238; bh=PuTfWYxQLhTAjaDvea6gKVcCYIdp2RUj6VBNyhU8ZZo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NQofG2QVvUNyK5e1afjaX2K7+wJsDecGoeF2EOLKc1waVTQ2NUQR5M2tub1kMSWDZ tBofVRWhX+fs3G+Ey9mIwSnS8LxfdHUSYCGPbtILiVgY/8JKMEONZYjY+fkKxCnpJF jrETXvS3AoL2MJp2xYkVVgxUD+ZyJILy6jtaesiu6MF1XxzU6VXaZqkQSZglY3nHX7 YJMQsVBQth82iwIHaXHtRiusoyP2hztsfrBwvVfzGUd6mcq04d3CVg9k/6vpbz5u+L 6FMnqpPmyx2C7UzFC5EZexPqCQniTa/NoR6xzlg4zKKQvR6g/Z19zP9rQMwljJgYV+ kaQtxp+EZhAyw== From: Frederic Weisbecker <frederic@kernel.org> To: LKML <linux-kernel@vger.kernel.org> Cc: Dan Carpenter <dan.carpenter@linaro.org>, Boqun Feng <boqun.feng@gmail.com>, Joel Fernandes <joel@joelfernandes.org>, Josh Triplett <josh@joshtriplett.org>, Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, Neeraj Upadhyay <neeraj.upadhyay@amd.com>, "Paul E . McKenney" <paulmck@kernel.org>, Steven Rostedt <rostedt@goodmis.org>, Uladzislau Rezki <urezki@gmail.com>, rcu <rcu@vger.kernel.org>, Frederic Weisbecker <frederic@kernel.org> Subject: [PATCH 23/23] locktorture: Check the correct variable for allocation failure Date: Tue, 10 Oct 2023 13:59:21 +0200 Message-Id: <20231010115921.988766-24-frederic@kernel.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20231010115921.988766-1-frederic@kernel.org> References: <20231010115921.988766-1-frederic@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.4 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Tue, 10 Oct 2023 05:02:18 -0700 (PDT) X-Spam-Level: ** X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779369865791232037 X-GMAIL-MSGID: 1779369865791232037 |
Series |
RCU/lock torture updates for v6.7
|
|
Commit Message
Frederic Weisbecker
Oct. 10, 2023, 11:59 a.m. UTC
From: Dan Carpenter <dan.carpenter@linaro.org> There is a typo so this checks the wrong variable. "chains" plural vs "chain" singular. We already know that "chains" is non-zero. Fixes: 7f993623e9eb ("locktorture: Add call_rcu_chains module parameter") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Frederic Weisbecker <frederic@kernel.org> --- kernel/locking/locktorture.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Tue, Oct 10, 2023 at 01:59:21PM +0200, Frederic Weisbecker wrote: > From: Dan Carpenter <dan.carpenter@linaro.org> > > There is a typo so this checks the wrong variable. "chains" plural vs > "chain" singular. We already know that "chains" is non-zero. > > Fixes: 7f993623e9eb ("locktorture: Add call_rcu_chains module parameter") > Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> > Signed-off-by: Frederic Weisbecker <frederic@kernel.org> Reviewed-by: Paul E. McKenney <paulmck@kernel.org> A name change to increase the Hamming distance would of course also be good, though less urgent. ;-) > --- > kernel/locking/locktorture.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c > index a3abcd136f56..69d3cd2cfc3b 100644 > --- a/kernel/locking/locktorture.c > +++ b/kernel/locking/locktorture.c > @@ -1075,7 +1075,7 @@ static int call_rcu_chain_init(void) > if (call_rcu_chains <= 0) > return 0; > call_rcu_chain = kcalloc(call_rcu_chains, sizeof(*call_rcu_chain), GFP_KERNEL); > - if (!call_rcu_chains) > + if (!call_rcu_chain) > return -ENOMEM; > for (i = 0; i < call_rcu_chains; i++) { > call_rcu_chain[i].crc_stop = false; > -- > 2.34.1 >
On Tue, Oct 10, 2023 at 06:55:40AM -0700, Paul E. McKenney wrote: > On Tue, Oct 10, 2023 at 01:59:21PM +0200, Frederic Weisbecker wrote: > > From: Dan Carpenter <dan.carpenter@linaro.org> > > > > There is a typo so this checks the wrong variable. "chains" plural vs > > "chain" singular. We already know that "chains" is non-zero. > > > > Fixes: 7f993623e9eb ("locktorture: Add call_rcu_chains module parameter") > > Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> > > Signed-off-by: Frederic Weisbecker <frederic@kernel.org> > > Reviewed-by: Paul E. McKenney <paulmck@kernel.org> > > A name change to increase the Hamming distance would of course also be > good, though less urgent. ;-) "Hamming distance" is such a great phrase. I'm going to use that every time I complain about confusingly similar variable names going forward. regards, dan carpenter
On Tue, Oct 10, 2023 at 05:07:00PM +0300, Dan Carpenter wrote: > On Tue, Oct 10, 2023 at 06:55:40AM -0700, Paul E. McKenney wrote: > > On Tue, Oct 10, 2023 at 01:59:21PM +0200, Frederic Weisbecker wrote: > > > From: Dan Carpenter <dan.carpenter@linaro.org> > > > > > > There is a typo so this checks the wrong variable. "chains" plural vs > > > "chain" singular. We already know that "chains" is non-zero. > > > > > > Fixes: 7f993623e9eb ("locktorture: Add call_rcu_chains module parameter") > > > Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> > > > Signed-off-by: Frederic Weisbecker <frederic@kernel.org> > > > > Reviewed-by: Paul E. McKenney <paulmck@kernel.org> > > > > A name change to increase the Hamming distance would of course also be > > good, though less urgent. ;-) > > "Hamming distance" is such a great phrase. I'm going to use that every > time I complain about confusingly similar variable names going forward. Glad you like it! But the horrible thing is that I first heard that phrase back in the 1970s, and I am the guilty party who created these particular too-similar variable names. (Why has the phrase fallen out of favor? No idea, really, but one guess has to do with the fact that current error-correcting codes must deal with different probabilities of different bits flipping in different directions, so you would instead needs a weirdly weighted variant of Hamming distance to accomplish anything with modern error-correcting codes.) But how about something like the following? Thanx, paul ------------------------------------------------------------------------ diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c index 991496afc0d9..48fd4562a754 100644 --- a/kernel/locking/locktorture.c +++ b/kernel/locking/locktorture.c @@ -126,7 +126,7 @@ struct call_rcu_chain { struct rcu_head crc_rh; bool crc_stop; }; -struct call_rcu_chain *call_rcu_chain; +struct call_rcu_chain *call_rcu_chain_list; /* Forward reference. */ static void lock_torture_cleanup(void); @@ -1106,12 +1106,12 @@ static int call_rcu_chain_init(void) if (call_rcu_chains <= 0) return 0; - call_rcu_chain = kcalloc(call_rcu_chains, sizeof(*call_rcu_chain), GFP_KERNEL); - if (!call_rcu_chain) + call_rcu_chain_list = kcalloc(call_rcu_chains, sizeof(*call_rcu_chain_list), GFP_KERNEL); + if (!call_rcu_chain_list) return -ENOMEM; for (i = 0; i < call_rcu_chains; i++) { - call_rcu_chain[i].crc_stop = false; - call_rcu(&call_rcu_chain[i].crc_rh, call_rcu_chain_cb); + call_rcu_chain_list[i].crc_stop = false; + call_rcu(&call_rcu_chain_list[i].crc_rh, call_rcu_chain_cb); } return 0; } @@ -1121,13 +1121,13 @@ static void call_rcu_chain_cleanup(void) { int i; - if (!call_rcu_chain) + if (!call_rcu_chain_list) return; for (i = 0; i < call_rcu_chains; i++) - smp_store_release(&call_rcu_chain[i].crc_stop, true); + smp_store_release(&call_rcu_chain_list[i].crc_stop, true); rcu_barrier(); - kfree(call_rcu_chain); - call_rcu_chain = NULL; + kfree(call_rcu_chain_list); + call_rcu_chain_list = NULL; } static struct notifier_block lock_torture_stall_block;
On Tue, Oct 10, 2023 at 08:53:36AM -0700, Paul E. McKenney wrote: > On Tue, Oct 10, 2023 at 05:07:00PM +0300, Dan Carpenter wrote: > > On Tue, Oct 10, 2023 at 06:55:40AM -0700, Paul E. McKenney wrote: > > > On Tue, Oct 10, 2023 at 01:59:21PM +0200, Frederic Weisbecker wrote: > > > > From: Dan Carpenter <dan.carpenter@linaro.org> > > > > > > > > There is a typo so this checks the wrong variable. "chains" plural vs > > > > "chain" singular. We already know that "chains" is non-zero. > > > > > > > > Fixes: 7f993623e9eb ("locktorture: Add call_rcu_chains module parameter") > > > > Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> > > > > Signed-off-by: Frederic Weisbecker <frederic@kernel.org> > > > > > > Reviewed-by: Paul E. McKenney <paulmck@kernel.org> > > > > > > A name change to increase the Hamming distance would of course also be > > > good, though less urgent. ;-) > > > > "Hamming distance" is such a great phrase. I'm going to use that every > > time I complain about confusingly similar variable names going forward. > > Glad you like it! > > But the horrible thing is that I first heard that phrase back in > the 1970s, and I am the guilty party who created these particular > too-similar variable names. (Why has the phrase fallen out of favor? > No idea, really, but one guess has to do with the fact that current > error-correcting codes must deal with different probabilities of different > bits flipping in different directions, so you would instead needs a > weirdly weighted variant of Hamming distance to accomplish anything with > modern error-correcting codes.) > > But how about something like the following? > Looks good! regards, dan carpenter
diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c index a3abcd136f56..69d3cd2cfc3b 100644 --- a/kernel/locking/locktorture.c +++ b/kernel/locking/locktorture.c @@ -1075,7 +1075,7 @@ static int call_rcu_chain_init(void) if (call_rcu_chains <= 0) return 0; call_rcu_chain = kcalloc(call_rcu_chains, sizeof(*call_rcu_chain), GFP_KERNEL); - if (!call_rcu_chains) + if (!call_rcu_chain) return -ENOMEM; for (i = 0; i < call_rcu_chains; i++) { call_rcu_chain[i].crc_stop = false;