mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Will Deacon <will.deacon@arm.com>,
	linux-kernel@vger.kernel.org,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	lttng-dev@lists.lttng.org, Nathan Lynch <Nathan_Lynch@mentor.com>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jakub Jelinek <jakub@redhat.com>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: current_thread_info() not respecting program order with gcc 4.8.x
Date: Tue, 19 Nov 2013 18:33:12 +0100	[thread overview]
Message-ID: <20131119173312.GP16796@laptop.programming.kicks-ass.net> (raw)
In-Reply-To: <1656507422.70913.1384880540574.JavaMail.zimbra@efficios.com>

On Tue, Nov 19, 2013 at 05:02:20PM +0000, Mathieu Desnoyers wrote:
> Unfortunately I don't have a ARM cross-compiler setup ready. Nathan could test
> it for us though.
> 
> It might shuffle things around enough to work around the issue, but with the
> approach you propose, I would be concerned about the compiler being within
> its rights to reorder the code into the following sequence:
> 
> struct thread_info *ptra, *ptrb;
> 
> ptra = current_thread_info();
> /*
>  * each current_thread_info() would have a clobber on *sp, which orders
>  * those two wrt each other.
>   */
> ptrb = current_thread_info();
> 
> load from ptra->preempt_count;
> /*
>  * however, the following accesses that depend on ptra and ptrb could be
>  * reordered if the compiler has no way to know that ptra and ptrb are
>  * aliased.
>  */
> store to ptrb->preempt_count;
> 
> One question that might be worth asking: with the local register variable
> extension (http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Local-Reg-Vars.html#Local-Reg-Vars)
> (thanks to Jakub for the pointer), should the compiler consider two variables
> bound to the same register as being aliased or not ? AFAIU, local reg vars appear
> to be architecture-specific, so maybe there is something fishy on ARM ?

Might help if you ask where the GCC people are on CC ;-)

  reply	other threads:[~2013-11-19 17:33 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <52803E5D.3050109@mentor.com>
     [not found] ` <52851395.3010306@mentor.com>
     [not found]   ` <67652521.68027.1384482849638.JavaMail.zimbra@efficios.com>
2013-11-19 15:29     ` Mathieu Desnoyers
2013-11-19 15:57       ` Peter Zijlstra
2013-11-19 16:13         ` Jakub Jelinek
2013-11-19 16:21           ` Peter Zijlstra
2013-11-19 16:05       ` Will Deacon
2013-11-19 17:02         ` Mathieu Desnoyers
2013-11-19 17:33           ` Peter Zijlstra [this message]
2013-11-19 21:56             ` Multiple local register variables w/ same register Richard Henderson
2013-11-19 22:08               ` Jakub Jelinek
2013-11-19 22:13               ` Måns Rullgård
2013-11-19 22:25               ` Mathieu Desnoyers
2013-11-19 22:34                 ` [lttng-dev] " Mathieu Desnoyers
2013-11-20  0:41       ` current_thread_info() not respecting program order with gcc 4.8.x Linus Torvalds
2013-11-20 15:10         ` Mathieu Desnoyers
2013-11-21 16:02         ` Alexander Holler
2013-11-21 22:12           ` Luis Lozano
2013-11-21 22:32           ` Linus Torvalds
2013-11-21 23:18             ` Alexander Holler
2013-11-21 23:45               ` Luis Lozano
2013-11-22  0:39                 ` Jakub Jelinek
2013-11-22  1:57                   ` Mathieu Desnoyers
2013-11-22  2:36                     ` Luis Lozano
2013-11-22  3:38                       ` Mathieu Desnoyers
2013-11-22  8:18                         ` Luis Lozano
2013-11-22  8:33                           ` Luis Lozano
2013-11-22 13:06                           ` Mathieu Desnoyers
2013-11-22 20:33                             ` [lttng-dev] " Mathieu Desnoyers
2013-11-22  0:17               ` Linus Torvalds
2013-11-22  0:34                 ` Alexander Holler
2013-11-21  1:52 Luis Lozano

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=20131119173312.GP16796@laptop.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=Catalin.Marinas@arm.com \
    --cc=Nathan_Lynch@mentor.com \
    --cc=akpm@linux-foundation.org \
    --cc=jakub@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lttng-dev@lists.lttng.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=rth@twiddle.net \
    --cc=torvalds@linux-foundation.org \
    --cc=will.deacon@arm.com \
    /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

all inboxes | Powered by JetHome®