Date:   Wed, 25 Jan 2023 14:01:45 -0800
From:   "Paul E. McKenney" <paulmck@kernel.org>
To:     Jonas Oberhauser <jonas.oberhauser@huaweicloud.com>
Cc:     Alan Stern <stern@rowland.harvard.edu>,
        Andrea Parri <parri.andrea@gmail.com>,
        Jonas Oberhauser <jonas.oberhauser@huawei.com>,
        Peter Zijlstra <peterz@infradead.org>, will <will@kernel.org>,
        "boqun.feng" <boqun.feng@gmail.com>, npiggin <npiggin@gmail.com>,
        dhowells <dhowells@redhat.com>,
        "j.alglave" <j.alglave@ucl.ac.uk>,
        "luc.maranget" <luc.maranget@inria.fr>, akiyks <akiyks@gmail.com>,
        dlustig <dlustig@nvidia.com>, joel <joel@joelfernandes.org>,
        urezki <urezki@gmail.com>,
        quic_neeraju <quic_neeraju@quicinc.com>,
        frederic <frederic@kernel.org>,
        Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: [Patch 1/2] tools/memory-model: Update some warning labels
Message-ID: <20230125220145.GS2948950@paulmck-ThinkPad-P17-Gen-1>
Reply-To: paulmck@kernel.org
References: <Y9GO3xEYkIQq/qSl@rowland.harvard.edu>
 <Y9GPI/g23YWx+0Ce@rowland.harvard.edu>
 <16ca40c7-ba9d-6741-e7fc-fd553c80a757@huaweicloud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <16ca40c7-ba9d-6741-e7fc-fd553c80a757@huaweicloud.com>
Precedence: bulk

On Wed, Jan 25, 2023 at 09:35:44PM +0100, Jonas Oberhauser wrote:
> 
> 
> On 1/25/2023 9:20 PM, Alan Stern wrote:
> > Some of the warning labels used in the LKMM are unfortunately
> > ambiguous.  In particular, the same warning is used for both an
> > unmatched rcu_read_lock() call and for an unmatched rcu_read_unlock()
> > call.  Likewise for the srcu_* equivalents.  Also, the warning about
> > passing a wrong value to srcu_read_unlock() -- i.e., a value different
> > from the one returned by the matching srcu_read_lock() -- talks about
> > bad nesting rather than non-matching values.
> > 
> > Let's update the warning labels to make their meanings more clear.
> > 
> > Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> 
> Reviewed-by: Jonas Oberhauser <jonas.oberhauser@huaweicloud.com>

Applied for further review and testing.  I am thinking in terms of v6.4,
that is, the merge window after the upcoming one.  Or does someone need
it earlier?

							Thanx, Paul

> > ---
> > 
> >   tools/memory-model/linux-kernel.bell |   10 +++++-----
> >   1 file changed, 5 insertions(+), 5 deletions(-)
> > 
> > Index: usb-devel/tools/memory-model/linux-kernel.bell
> > ===================================================================
> > --- usb-devel.orig/tools/memory-model/linux-kernel.bell
> > +++ usb-devel/tools/memory-model/linux-kernel.bell
> > @@ -53,8 +53,8 @@ let rcu-rscs = let rec
> >   	in matched
> >   (* Validate nesting *)
> > -flag ~empty Rcu-lock \ domain(rcu-rscs) as unbalanced-rcu-locking
> > -flag ~empty Rcu-unlock \ range(rcu-rscs) as unbalanced-rcu-locking
> > +flag ~empty Rcu-lock \ domain(rcu-rscs) as unmatched-rcu-lock
> > +flag ~empty Rcu-unlock \ range(rcu-rscs) as unmatched-rcu-unlock
> >   (* Compute matching pairs of nested Srcu-lock and Srcu-unlock *)
> >   let srcu-rscs = let rec
> > @@ -69,14 +69,14 @@ let srcu-rscs = let rec
> >   	in matched
> >   (* Validate nesting *)
> > -flag ~empty Srcu-lock \ domain(srcu-rscs) as unbalanced-srcu-locking
> > -flag ~empty Srcu-unlock \ range(srcu-rscs) as unbalanced-srcu-locking
> > +flag ~empty Srcu-lock \ domain(srcu-rscs) as unmatched-srcu-lock
> > +flag ~empty Srcu-unlock \ range(srcu-rscs) as unmatched-srcu-unlock
> >   (* Check for use of synchronize_srcu() inside an RCU critical section *)
> >   flag ~empty rcu-rscs & (po ; [Sync-srcu] ; po) as invalid-sleep
> >   (* Validate SRCU dynamic match *)
> > -flag ~empty different-values(srcu-rscs) as srcu-bad-nesting
> > +flag ~empty different-values(srcu-rscs) as srcu-bad-value-match
> >   (* Compute marked and plain memory accesses *)
> >   let Marked = (~M) | IW | Once | Release | Acquire | domain(rmw) | range(rmw) |
>