Received-SPF: pass (google.com: domain of linux-kernel+bounces-98269-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: <2d508574-c2b8-489b-a26d-71b1c36961cf@linux.dev> <tencent_688B20450ABBA409637C5A4BC3A7B0191D07@qq.com>
In-Reply-To: <tencent_688B20450ABBA409637C5A4BC3A7B0191D07@qq.com>
From: Greg Sword <gregsword0@gmail.com>
Date: Mon, 11 Mar 2024 01:00:20 +0800
Message-ID: <CAEz=LctG46xSHVxRg0VwnfCpv+uyOHdb0jqQ+WJNc7zSnMA2Ng@mail.gmail.com>
Subject: Re: [PATCH] RDMA/siw: Reuse value read using READ_ONCE instead of
 re-reading it
To: linke li <lilinke99@qq.com>
Cc: yanjun.zhu@linux.dev, bmt@zurich.ibm.com, jgg@ziepe.ca, leon@kernel.org, 
	linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Mar 10, 2024 at 8:36=E2=80=AFPM linke li <lilinke99@qq.com> wrote:
>
> > In a complicated environment, for example, this function is called many
> > times at the same time and orqe->flags is changed at the same time, I a=
m
> > not sure if this will introduce risks or not.
>
> I think one function of READ_ONCE is to read a valid value while the valu=
e
> may change concurrently. And there is a smp() above the READ_ONCE, which
> means that the READ_ONCE is well ordered. I think it is kind of safe here=
.

This is not a smp problem. Compared with the original source, your
commit introduces a time slot.

>
> > if you need to ensure the consistency of the flags throughout the funct=
ion, not sure if the following is better or not.
>
> > if (((orqe_flags=3DREAD_ONCE(orqe->flags))) & SIW_WQE_VALID) {
>
> This patch looks like exactly do the same things. The only difference I
> think is the code style.

No.

>
> Thanks,
> Linke
>
>