Received-SPF: pass (google.com: domain of linux-kernel+bounces-49460-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <1705477714-10467-1-git-send-email-zhiguo.niu@unisoc.com>
 <2d1f4f16-6d66-4449-a7b7-5e2b2a4eaeb3@acm.org> <Zbv31aq6aZuSXpY1@boqun-archlinux>
 <c485e96c-6aed-4c4c-bbba-de5c8784be69@acm.org> <ZbwSxGpySa8RBt9A@boqun-archlinux>
 <891016e2-0f3a-4617-bb8e-a2a3af0f78c8@acm.org>
In-Reply-To: <891016e2-0f3a-4617-bb8e-a2a3af0f78c8@acm.org>
From: Zhiguo Niu <niuzhiguo84@gmail.com>
Date: Fri, 2 Feb 2024 16:19:34 +0800
Message-ID: <CAHJ8P3+wCaUWkCshgEPYu8Bdjchp4m2F62X1fabw=5Fiogzu+g@mail.gmail.com>
Subject: Re: [PATCH V2] lockdep: fix deadlock issue between lockdep and rcu
To: Bart Van Assche <bvanassche@acm.org>
Cc: Boqun Feng <boqun.feng@gmail.com>, Zhiguo Niu <zhiguo.niu@unisoc.com>, peterz@infradead.org, 
	mingo@redhat.com, will@kernel.org, longman@redhat.com, 
	linux-kernel@vger.kernel.org, ke.wang@unisoc.com, xuewen.yan@unisoc.com, 
	Carlos Llamas <cmllamas@google.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear All,
Thanks for your discussion and suggestions , I update and send patch
version3 according to your comments.
thanks!

On Fri, Feb 2, 2024 at 10:13=E2=80=AFAM Bart Van Assche <bvanassche@acm.org=
> wrote:
>
> On 2/1/24 13:53, Boqun Feng wrote:
> > Have you checked the change in the patch? Now call_rcu_zapped() has bee=
n
> > splitted into two parts: preparing the callback and calling call_rcu(),
> > the preparing part checks and sets the delayed_free.scheduled under
> > graph_lock(), so only one CPU/thread will win and do the actual
> > call_rcu(). And the RCU callback free_zapped_rcu() will unset
> > delayed_free.scheduled, again under graph_lock().
> >
> > If you think it's still possible, could you provide a case where the
> > race may happen?
>
> Yes, I noticed that call_rcu_zapped() has been split but the first time
> I took a look at this patch I wasn't sure that the new code is correct.
> After having taken a second look, the new mechanism for deciding whether
> or not to invoke call_rcu() seems fine to me.
>
> Bart.