lkmm.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Jonas Oberhauser <jonas.oberhauser@huaweicloud.com>
To: David Laight <David.Laight@ACULAB.COM>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	'Alan Stern' <stern@rowland.harvard.edu>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Will Deacon <will@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	John Stultz <jstultz@google.com>,
	Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>,
	Frederic Weisbecker <frederic@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Uladzislau Rezki <urezki@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Ingo Molnar <mingo@redhat.com>, Waiman Long <longman@redhat.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Vlastimil Babka <vbabka@suse.cz>,
	"maged.michael@gmail.com" <maged.michael@gmail.com>,
	Mateusz Guzik <mjguzik@gmail.com>, Gary Guo <gary@garyguo.net>,
	"rcu@vger.kernel.org" <rcu@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"lkmm@lists.linux.dev" <lkmm@lists.linux.dev>
Subject: Re: [PATCH 1/2] compiler.h: Introduce ptr_eq() to preserve address dependency
Date: Mon, 7 Oct 2024 16:59:06 +0200	[thread overview]
Message-ID: <b86aac93-d1f7-4716-9283-4a8367b20e48@huaweicloud.com> (raw)
In-Reply-To: <43788527053542e78001820857445e4d@AcuMS.aculab.com>



Am 10/7/2024 um 3:18 PM schrieb David Laight:
> From: Jonas Oberhauser
>> Sent: 07 October 2024 12:55
>>
>> Am 10/3/2024 um 3:23 PM schrieb Mathieu Desnoyers:
>>> What _does_ work however are the following two approaches:
>>>
>>> 1) Perform the equality check on the original variables, creating
>>> new versions (with OPTIMIZER_HIDE_VAR) of both variables for the
>>> rest of their use, therefore making sure the pointer dereference
>>> are not derived from versions of the variables which were compared
>>> with another pointer. (as suggested by Boqun)
>>
>> This should not be guaranteed to work, because right after the
>> comparison the compiler can do b=a, then it doesn't matter how much you
>> hide afterwards.
>>
>> However it might work if you escape the addresses of a and b first, in
>> which case the compiler will not do b=a anymore, but it might force the
>> compiler to put a and b on the stack, which has some performance impact.
> 
> Nope, as pointed out last week, the compiler can move the 'a == b'
> check to before the OPTIMISER_HID_VAR() and then use the same register
> for both of them.
> 

Since the addresses of a and b have escaped, I don't think it can still 
put them into the same register (or memory location).

Other threads could be temporarily modifying (inside the escape code) or 
concurrently reading (after the escape code) the two variables 
independently.

Something in the direction of

a = ...;
...
b = ...;

escape(&a);
escape(&b);
if (a == b) {
    OPTIMIZER_HIDE_VAR(b);
    *b;
}


Here doing b=a after a==b would (from the point of view of compiler) 
potentially introduce a data race.

As I pointed out earlier, the compiler might be able to prove that it is 
a benign data race though and theoretically still do b=a. But if you 
declare b as volatile on top...

Anyways, the ptr_eq way is much more obvious.

   jonas


  parent reply	other threads:[~2024-10-07 14:59 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-28 13:51 [PATCH 0/2] Introduce ptr_eq() to preserve address dependency Mathieu Desnoyers
2024-09-28 13:51 ` [PATCH 1/2] compiler.h: " Mathieu Desnoyers
2024-09-28 14:49   ` Alan Stern
2024-09-28 15:30     ` Mathieu Desnoyers
2024-09-28 15:32     ` Mathieu Desnoyers
2024-09-28 15:49       ` Alan Stern
2024-09-28 15:55         ` Mathieu Desnoyers
2024-09-28 21:15           ` Alan Stern
2024-09-30  9:42             ` Jonas Oberhauser
2024-09-30 11:04               ` Paul E. McKenney
2024-09-30 12:06                 ` Jonas Oberhauser
2024-09-30 13:54                   ` Paul E. McKenney
2024-09-28 22:26           ` Alan Huang
2024-09-28 23:55             ` Boqun Feng
2024-09-29  0:20               ` Alan Huang
2024-09-30  8:57             ` Jonas Oberhauser
2024-09-30  9:15               ` Alan Huang
2024-09-30  9:27                 ` Alan Huang
2024-09-30  9:33                   ` Jonas Oberhauser
2024-09-30 10:12                     ` Alan Huang
2024-09-30 11:26     ` Jonas Oberhauser
2024-09-30 16:43       ` Alan Stern
2024-09-30 17:05         ` Jonas Oberhauser
2024-09-30 18:53           ` Alan Stern
2024-10-01 17:11             ` David Laight
2024-10-01 22:57               ` 'Alan Stern'
2024-10-02  8:13                 ` David Laight
2024-10-02 14:14                   ` 'Alan Stern'
2024-10-02 15:24                     ` David Laight
2024-10-03  1:50                       ` 'Alan Stern'
2024-10-03 13:23                         ` Mathieu Desnoyers
2024-10-03 17:07                           ` David Laight
2024-10-03 18:00                             ` Mathieu Desnoyers
2024-10-07 11:54                           ` Jonas Oberhauser
2024-10-07 13:18                             ` David Laight
2024-10-07 13:21                               ` Mathieu Desnoyers
2024-10-07 14:59                               ` Jonas Oberhauser [this message]
2024-09-28 23:24   ` Gary Guo
2024-09-29 10:36     ` Mathieu Desnoyers
2024-09-28 13:51 ` [PATCH 2/2] Documentation: RCU: Refer to ptr_eq() Mathieu Desnoyers
2024-09-28 14:58   ` Alan Stern
2024-09-28 15:09     ` Mathieu Desnoyers

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=b86aac93-d1f7-4716-9283-4a8367b20e48@huaweicloud.com \
    --to=jonas.oberhauser@huaweicloud.com \
    --cc=David.Laight@ACULAB.COM \
    --cc=Neeraj.Upadhyay@amd.com \
    --cc=bigeasy@linutronix.de \
    --cc=boqun.feng@gmail.com \
    --cc=frederic@kernel.org \
    --cc=gary@garyguo.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=jiangshanlai@gmail.com \
    --cc=joel@joelfernandes.org \
    --cc=josh@joshtriplett.org \
    --cc=jstultz@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lkmm@lists.linux.dev \
    --cc=longman@redhat.com \
    --cc=maged.michael@gmail.com \
    --cc=mark.rutland@arm.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@redhat.com \
    --cc=mjguzik@gmail.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=qiang.zhang1211@gmail.com \
    --cc=rcu@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=stern@rowland.harvard.edu \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=urezki@gmail.com \
    --cc=vbabka@suse.cz \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).