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;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Joel Fernandes <joel@joelfernandes.org>
Mime-Version: 1.0 (1.0)
Subject: Re: [RFC 0/2] srcu: Remove pre-flip memory barrier
Date:   Tue, 20 Dec 2022 21:41:17 -0500
Message-Id: <0B1950D8-9319-4F25-B14B-4ED949A57BE0@joelfernandes.org>
References: <20221221004957.GA29021@lothringen>
Cc:     linux-kernel@vger.kernel.org,
        Josh Triplett <josh@joshtriplett.org>,
        Lai Jiangshan <jiangshanlai@gmail.com>,
        Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
        "Paul E. McKenney" <paulmck@kernel.org>, rcu@vger.kernel.org,
        Steven Rostedt <rostedt@goodmis.org>
In-Reply-To: <20221221004957.GA29021@lothringen>
To:     Frederic Weisbecker <frederic@kernel.org>
Precedence: bulk


> On Dec 20, 2022, at 7:50 PM, Frederic Weisbecker <frederic@kernel.org> wro=
te:
>=20
> =EF=BB=BFOn Tue, Dec 20, 2022 at 07:15:00PM -0500, Joel Fernandes wrote:
>> On Tue, Dec 20, 2022 at 5:45 PM Frederic Weisbecker <frederic@kernel.org>=
 wrote:
>> Agreed about (1).
>>=20
>>> _ In (2), E pairs with the address-dependency between idx and lock_count=
.
>>=20
>> But that is not the only reason. If that was the only reason for (2),
>> then there is an smp_mb() just before the next-scan post-flip before
>> the lock counts are read.
>=20
> The post-flip barrier makes sure the new idx is visible on the next READER=
's
> turn, but it doesn't protect against the fact that "READ idx then WRITE lo=
ck[idx]"
> may appear unordered from the update side POV if there is no barrier betwe=
en the
> scan and the flip.
>=20
> If you remove the smp_mb() from the litmus test I sent, things explode.

Sure I see what you are saying and it=E2=80=99s a valid point as well. Howev=
er why do you need memory barrier D (labeled such in the kernel code) for th=
at? You already have a memory barrier A before the lock count is read. That w=
ill suffice for the ordering pairing with the addr dependency.
In other words, if updater sees readers lock counts, then reader would be ma=
king those lock count updates on post-flip inactive index, not the one being=
 scanned as you wanted, and you will accomplish that just with the mem barri=
er A.

So D fixes the above issue you are talking about (lock count update), howeve=
r that is already fixed by the memory barrier A. But you still need D for th=
e issue I mentioned (unlock counts vs flip).

That=E2=80=99s just my opinion and let=E2=80=99s discuss more because I cann=
ot rule out that I am missing something with this complicated topic ;-)

Thanks.=