Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35;
Date:   Wed, 11 Oct 2023 09:46:25 +0300
From:   Dan Carpenter <dan.carpenter@linaro.org>
To:     "Paul E. McKenney" <paulmck@kernel.org>
Cc:     Frederic Weisbecker <frederic@kernel.org>,
        LKML <linux-kernel@vger.kernel.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>,
        Steven Rostedt <rostedt@goodmis.org>,
        Uladzislau Rezki <urezki@gmail.com>, rcu <rcu@vger.kernel.org>
Subject: Re: [PATCH 23/23] locktorture: Check the correct variable for
 allocation failure
Message-ID: <029de83a-dcf1-439d-8d6b-7267d2636e37@kadam.mountain>
References: <20231010115921.988766-1-frederic@kernel.org>
 <20231010115921.988766-24-frederic@kernel.org>
 <97ecfb49-e500-45f4-86bb-769b2d32e91c@paulmck-laptop>
 <beaba092-8545-43c9-9b65-6386f718cb01@kadam.mountain>
 <b9a976f6-c002-4e3d-8c6d-cef3953bd3a7@paulmck-laptop>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b9a976f6-c002-4e3d-8c6d-cef3953bd3a7@paulmck-laptop>
Precedence: bulk

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