LKML Archive on
 help / color / Atom feed
From: Qian Cai <>
To: Will Deacon <>
Cc: "Paul E. McKenney" <>,
	Elver Marco <>,
	LKML <>,
	Ingo Molnar <>,
	"Peter Zijlstra (Intel)" <>
Subject: Re: [PATCH -next v2] locking/osq_lock: annotate a data race in osq_lock
Date: Mon, 11 May 2020 12:44:26 -0400
Message-ID: <> (raw)
In-Reply-To: <20200511155812.GB22270@willie-the-truck>

> On May 11, 2020, at 11:58 AM, Will Deacon <> wrote:
> I'm fine with the data_race() placement, but I don't find the comment
> very helpful. We assign the result of a READ_ONCE() to 'prev' in the
> loop, so I don't think that the cpu_relax() is really relevant.
> The reason we don't need READ_ONCE() here is because if we race with
> the writer then either we'll go round the loop again after accidentally
> thinking prev->next != node, or we'll erroneously attempt the cmpxchg()
> because we thought they were equal and that will fail.
> Make sense?

I think the significant concern from the previous reviews was if compilers could prove that prev->next == node was always true because it had no knowledge of the concurrency, and then took out the whole if statement away resulting in an infinite loop.

The comment tried to explain that the cpu_relax() would save us from the infinite loop in theory here.

  parent reply index

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-11 13:54 Qian Cai
2020-05-08 20:59 ` Qian Cai
2020-05-09  4:33   ` Paul E. McKenney
2020-05-09 13:01     ` Qian Cai
2020-05-09 16:12       ` Paul E. McKenney
2020-05-09 16:53         ` Qian Cai
2020-05-09 21:36           ` Paul E. McKenney
2020-05-11 15:58             ` Will Deacon
2020-05-11 16:43               ` Paul E. McKenney
2020-05-11 16:52                 ` Will Deacon
2020-05-11 17:29                   ` Paul E. McKenney
2020-05-11 17:34                     ` Will Deacon
2020-05-11 18:07                       ` Paul E. McKenney
2020-05-11 16:44               ` Qian Cai [this message]
2020-05-11 16:54                 ` Will Deacon
2020-05-11 17:10                   ` Qian Cai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on

Archives are clonable:
	git clone --mirror lkml/git/0.git
	git clone --mirror lkml/git/1.git
	git clone --mirror lkml/git/2.git
	git clone --mirror lkml/git/3.git
	git clone --mirror lkml/git/4.git
	git clone --mirror lkml/git/5.git
	git clone --mirror lkml/git/6.git
	git clone --mirror lkml/git/7.git
	git clone --mirror lkml/git/8.git
	git clone --mirror lkml/git/9.git
	git clone --mirror lkml/git/10.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ \
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone