Peter Zijlstra wrote:
>
> Paulmck actually has an example of that somewhere; ISTR that particular
> case actually got fixed by GCC, but I'd really _love_ for some compiler
> people (both GCC and LLVM) to state that their respective compilers will
> not do load/store tearing for machine word sized
On Wed, Aug 21, 2019 at 11:48:43AM -0400, Mathieu Desnoyers wrote:
> - On Aug 21, 2019, at 8:33 AM, Peter Zijlstra pet...@infradead.org wrote:
>
> > On Wed, Aug 21, 2019 at 06:23:10AM -0700, Paul E. McKenney wrote:
> >> On Wed, Aug 21, 2019 at 11:32:01AM +0100, Will Deacon wrote:
> >
> >> >
On Wed, Aug 21, 2019 at 06:56:10AM -0700, Paul E. McKenney wrote:
> On Wed, Aug 21, 2019 at 02:32:48PM +0100, Will Deacon wrote:
> > On Wed, Aug 21, 2019 at 06:23:10AM -0700, Paul E. McKenney wrote:
> > > On Wed, Aug 21, 2019 at 11:32:01AM +0100, Will Deacon wrote:
> > > > void bar(u64 *x)
> > > >
On Wed, Aug 21, 2019 at 11:48:43AM -0400, Mathieu Desnoyers wrote:
> - On Aug 21, 2019, at 8:33 AM, Peter Zijlstra pet...@infradead.org wrote:
>
> > On Wed, Aug 21, 2019 at 06:23:10AM -0700, Paul E. McKenney wrote:
> >> On Wed, Aug 21, 2019 at 11:32:01AM +0100, Will Deacon wrote:
> >
> >> >
- On Aug 21, 2019, at 8:33 AM, Peter Zijlstra pet...@infradead.org wrote:
> On Wed, Aug 21, 2019 at 06:23:10AM -0700, Paul E. McKenney wrote:
>> On Wed, Aug 21, 2019 at 11:32:01AM +0100, Will Deacon wrote:
>
>> > and so it is using a store-pair instruction to reduce the complexity in
>> >
On Wed, Aug 21, 2019 at 06:23:10AM -0700, Paul E. McKenney wrote:
> On Wed, Aug 21, 2019 at 11:32:01AM +0100, Will Deacon wrote:
> > and so it is using a store-pair instruction to reduce the complexity in
> > the immediate generation. Thus, the 64-bit store will only have 32-bit
> > atomicity. In
On Wed, Aug 21, 2019 at 02:32:48PM +0100, Will Deacon wrote:
> On Wed, Aug 21, 2019 at 06:23:10AM -0700, Paul E. McKenney wrote:
> > On Wed, Aug 21, 2019 at 11:32:01AM +0100, Will Deacon wrote:
> > > void bar(u64 *x)
> > > {
> > > *(volatile u64 *)x = 0xabcdef10abcdef10;
> > > }
> > >
> > >
On Wed, Aug 21, 2019 at 06:23:10AM -0700, Paul E. McKenney wrote:
> On Wed, Aug 21, 2019 at 11:32:01AM +0100, Will Deacon wrote:
> > void bar(u64 *x)
> > {
> > *(volatile u64 *)x = 0xabcdef10abcdef10;
> > }
> >
> > then I get:
> >
> > bar:
> > mov w1, 61200
> > movkw1,
On Wed, Aug 21, 2019 at 11:32:01AM +0100, Will Deacon wrote:
> On Tue, Aug 20, 2019 at 01:29:32PM -0700, Paul E. McKenney wrote:
> > On Tue, Aug 20, 2019 at 03:56:12PM +0200, Peter Zijlstra wrote:
> > > On Sat, Aug 17, 2019 at 01:08:02AM -0700, Linus Torvalds wrote:
> > >
> > > > The data tearing
On Tue, Aug 20, 2019 at 01:29:32PM -0700, Paul E. McKenney wrote:
> On Tue, Aug 20, 2019 at 03:56:12PM +0200, Peter Zijlstra wrote:
> > On Sat, Aug 17, 2019 at 01:08:02AM -0700, Linus Torvalds wrote:
> >
> > > The data tearing issue is almost a non-issue. We're not going to add
> > > WRITE_ONCE()
On Tue, Aug 20, 2019 at 10:39:39PM +0200, Peter Zijlstra wrote:
> On Tue, Aug 20, 2019 at 01:31:35PM -0700, Paul E. McKenney wrote:
> > On Tue, Aug 20, 2019 at 04:01:16PM +0200, Peter Zijlstra wrote:
>
> > > We really should get the compiler folks to give us a
> > > -fno-pointer-provenance.
On Tue, Aug 20, 2019 at 01:31:35PM -0700, Paul E. McKenney wrote:
> On Tue, Aug 20, 2019 at 04:01:16PM +0200, Peter Zijlstra wrote:
> > We really should get the compiler folks to give us a
> > -fno-pointer-provenance. Waiting on the standards committee to get their
> > act together seems
On Tue, Aug 20, 2019 at 04:01:16PM +0200, Peter Zijlstra wrote:
> On Fri, Aug 16, 2019 at 09:52:17PM -0700, Paul E. McKenney wrote:
> > On Fri, Aug 16, 2019 at 03:57:43PM -0700, Linus Torvalds wrote:
> >
> > [ . . . ]
> >
> > > We add READ_ONCE and WRITE_ONCE annotations when they make sense.
On Tue, Aug 20, 2019 at 03:56:12PM +0200, Peter Zijlstra wrote:
> On Sat, Aug 17, 2019 at 01:08:02AM -0700, Linus Torvalds wrote:
>
> > The data tearing issue is almost a non-issue. We're not going to add
> > WRITE_ONCE() to these kinds of places for no good reason.
>
> Paulmck actually has an
On Fri, Aug 16, 2019 at 09:52:17PM -0700, Paul E. McKenney wrote:
> On Fri, Aug 16, 2019 at 03:57:43PM -0700, Linus Torvalds wrote:
>
> [ . . . ]
>
> > We add READ_ONCE and WRITE_ONCE annotations when they make sense. Not
> > because of some theoretical "compiler is free to do garbage"
> >
On Sat, Aug 17, 2019 at 01:08:02AM -0700, Linus Torvalds wrote:
> The data tearing issue is almost a non-issue. We're not going to add
> WRITE_ONCE() to these kinds of places for no good reason.
Paulmck actually has an example of that somewhere; ISTR that particular
case actually got fixed by
On 18/08/2019 00:00, Paul E. McKenney wrote:
[...]
> Linus noted that he believes that compilers for architectures supporting
> Linux can be trusted to avoid store-to-load transformations, invented
> stores, and unnecessary store tearing. Should these appear, Linus would
> report a bug against
Hi!
> The most I'll take is two separate patches. One is going to be marked
> for stable as it fixes a real bug. The other is more for cosmetic or
> theoretical issues, that I will state clearly "NOT FOR STABLE", such
> that the autosel doesn't take them.
Do we have standartized way to mark
On Sat, Aug 17, 2019 at 09:03:30PM +0100, Valentin Schneider wrote:
> Apologies to Steve for continuing this thread when all he wanted was moving
> an operation inside a mutex...
>
> On 17/08/2019 16:02, Mathieu Desnoyers wrote:
> [...]
> > However, if the state of "x" can be any pointer value,
On Sat, Aug 17, 2019 at 01:28:48AM -0700, Linus Torvalds wrote:
[ . . . ]
> Put another way: a WRITE_ONCE() without a paired READ_ONCE() is almost
> certainly pointless.
"Your honor, I have no further questions at this time, but I reserve
the right to recall this witness."
Outside of things
On Sat, Aug 17, 2019 at 12:40:40PM -0400, Steven Rostedt wrote:
> On Sat, 17 Aug 2019 11:55:17 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
> > - On Aug 17, 2019, at 11:26 AM, rostedt rost...@goodmis.org wrote:
> >
> > > On Sat, 17 Aug 2019 10:40:31 -0400 (EDT)
> > > Mathieu Desnoyers wrote:
>
Apologies to Steve for continuing this thread when all he wanted was moving
an operation inside a mutex...
On 17/08/2019 16:02, Mathieu Desnoyers wrote:
[...]
> However, if the state of "x" can be any pointer value, or a reference
> count value, then not using "WRITE_ONCE()" to store a constant
On Sat, 17 Aug 2019 11:53:41 -0400 (EDT)
Mathieu Desnoyers wrote:
> kernel/trace/trace.c:tracing_record_taskinfo_sched_switch()
> kernel/trace/trace.c:tracing_record_taskinfo()
>
> where @flags is used to control a few branches. I don't think any of those
> would end up causing corruption if
On Sat, 17 Aug 2019 11:55:17 -0400 (EDT)
Mathieu Desnoyers wrote:
> - On Aug 17, 2019, at 11:26 AM, rostedt rost...@goodmis.org wrote:
>
> > On Sat, 17 Aug 2019 10:40:31 -0400 (EDT)
> > Mathieu Desnoyers wrote:
> >
> >> > I'm now even more against adding the READ_ONCE() or WRITE_ONCE().
- On Aug 17, 2019, at 11:26 AM, rostedt rost...@goodmis.org wrote:
> On Sat, 17 Aug 2019 10:40:31 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> > I'm now even more against adding the READ_ONCE() or WRITE_ONCE().
>>
>> I'm not convinced by your arguments.
>
> Prove to me that there's an
- On Aug 17, 2019, at 11:42 AM, rostedt rost...@goodmis.org wrote:
> On Sat, 17 Aug 2019 10:27:39 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> I get your point wrt WRITE_ONCE(): since it's a cache it should not have
>> user-visible effects if a temporary incorrect value is observed. Well in
On Sat, 17 Aug 2019 10:27:39 -0400 (EDT)
Mathieu Desnoyers wrote:
> I get your point wrt WRITE_ONCE(): since it's a cache it should not have
> user-visible effects if a temporary incorrect value is observed. Well in
> reality, it's not a cache: if the lookup fails, it returns "<...>" instead,
>
On Sat, 17 Aug 2019 10:40:31 -0400 (EDT)
Mathieu Desnoyers wrote:
> > I'm now even more against adding the READ_ONCE() or WRITE_ONCE().
>
> I'm not convinced by your arguments.
Prove to me that there's an issue here beyond theoretical analysis,
then I'll consider that patch.
Show me a
- On Aug 17, 2019, at 4:44 AM, Linus Torvalds torva...@linux-foundation.org
wrote:
>
> But I'm seeing a lot of WRITE_ONCE(x, constantvalue) kind of things
> and don't seem to find a lot of reason to think that they are any
> inherently better than "x = constantvalue".
If the only states
- On Aug 16, 2019, at 10:13 PM, rostedt rost...@goodmis.org wrote:
> On Fri, 16 Aug 2019 21:36:49 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> - On Aug 16, 2019, at 5:04 PM, Linus Torvalds
>> torva...@linux-foundation.org
>> wrote:
>>
>> > On Fri, Aug 16, 2019 at 1:49 PM Thomas
- On Aug 16, 2019, at 3:15 PM, rostedt rost...@goodmis.org wrote:
> On Fri, 16 Aug 2019 13:19:20 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> - On Aug 16, 2019, at 12:25 PM, rostedt rost...@goodmis.org wrote:
>>
>> > On Fri, 16 Aug 2019 10:26:43 -0400 Mathieu Desnoyers
>> > wrote:
>> >
On Sat, Aug 17, 2019 at 1:28 AM Linus Torvalds
wrote:
>
>unsigned int bits = some_global_value;
>...test different bits in in 'bits' ...
>
> can easily cause multiple reads (particularly on a CPU that has a
> "test bits in memory" instruction and a lack of registers.
>
> So then doing it
On Fri, Aug 16, 2019 at 9:52 PM Paul E. McKenney wrote:
>
> > I'd love to have a flag that says "all undefined behavior is treated
> > as implementation-defined". There's a somewhat subtle - but very
> > important - difference there.
>
> It would also be nice to downgrade some of the undefined
On Fri, Aug 16, 2019, 18:36 Mathieu Desnoyers
wrote:
>
> If WRITE_ONCE has any use at all (protecting against store tearing and
> invented stores), it should be used even with a lock held in this
> scenario, because the lock does not prevent READ_ONCE() from observing
> transient states caused by
On Fri, Aug 16, 2019 at 03:57:43PM -0700, Linus Torvalds wrote:
[ . . . ]
> We add READ_ONCE and WRITE_ONCE annotations when they make sense. Not
> because of some theoretical "compiler is free to do garbage"
> arguments. If such garbage happens, we need to fix the compiler, the
> same way we
On Fri, 16 Aug 2019 21:36:49 -0400 (EDT)
Mathieu Desnoyers wrote:
> - On Aug 16, 2019, at 5:04 PM, Linus Torvalds
> torva...@linux-foundation.org wrote:
>
> > On Fri, Aug 16, 2019 at 1:49 PM Thomas Gleixner wrote:
> >
> >>
> >> Can we finally put a foot down and tell compiler and
- On Aug 16, 2019, at 6:57 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> So in general, we very much expect the compiler to do sane code
> generation, and not (for example) do store tearing on normal
> word-sized things or add writes that weren't there originally etc.
My
- On Aug 16, 2019, at 5:04 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
> On Fri, Aug 16, 2019 at 1:49 PM Thomas Gleixner wrote:
>>
>> Can we finally put a foot down and tell compiler and standard committee
>> people to stop this insanity?
>
> It's already effectively done.
>
>
- On Aug 16, 2019, at 4:49 PM, rostedt rost...@goodmis.org wrote:
> On Fri, 16 Aug 2019 16:44:10 -0400
> Joel Fernandes wrote:
>
>
>> I am also more on the side of using *_ONCE. To me, by principal, I
>> would be willing to convert any concurrent plain access using _ONCE,
>> just so we
On Fri, Aug 16, 2019 at 3:27 PM Valentin Schneider
wrote:
>
> How would you differentiate optimizations you want from those you don't with
> just a flag? There's a reason we use volatile casts instead of declaring
> everything volatile: we actually *want* those optimizations. It just so
> happens
On 16/08/2019 21:57, Joel Fernandes wrote:
>> Can we finally put a foot down and tell compiler and standard committee
>> people to stop this insanity?
>
> Sure, or could the compilers provide flags which prevent such optimization
> similar to -O* flags?
>
How would you differentiate
On Fri, Aug 16, 2019 at 1:49 PM Thomas Gleixner wrote:
>
> Can we finally put a foot down and tell compiler and standard committee
> people to stop this insanity?
It's already effectively done.
Yes, values can be read from memory multiple times if they need
reloading. So "READ_ONCE()" when the
On Fri, Aug 16, 2019 at 04:49:12PM -0400, Steven Rostedt wrote:
> On Fri, 16 Aug 2019 16:44:10 -0400
> Joel Fernandes wrote:
>
>
> > I am also more on the side of using *_ONCE. To me, by principal, I
> > would be willing to convert any concurrent plain access using _ONCE,
> > just so we don't
On Fri, Aug 16, 2019 at 10:49:04PM +0200, Thomas Gleixner wrote:
> On Fri, 16 Aug 2019, Joel Fernandes wrote:
> > On Fri, Aug 16, 2019 at 3:19 PM Alan Stern
> > wrote:
> > > On Fri, 16 Aug 2019, Mathieu Desnoyers wrote:
> > >
> > > > If you choose not to use READ_ONCE(), then the "load tearing"
On Fri, 16 Aug 2019, Joel Fernandes wrote:
> On Fri, Aug 16, 2019 at 3:19 PM Alan Stern wrote:
> > On Fri, 16 Aug 2019, Mathieu Desnoyers wrote:
> >
> > > If you choose not to use READ_ONCE(), then the "load tearing" issue can
> > > cause similar spurious 1 -> 0 -> 1 transitions near 16-bit
On Fri, 16 Aug 2019 16:44:10 -0400
Joel Fernandes wrote:
> I am also more on the side of using *_ONCE. To me, by principal, I
> would be willing to convert any concurrent plain access using _ONCE,
> just so we don't have to worry about it now or in the future and also
> documents the access.
>
On Fri, Aug 16, 2019 at 3:19 PM Alan Stern wrote:
>
> On Fri, 16 Aug 2019, Mathieu Desnoyers wrote:
>
> > If you choose not to use READ_ONCE(), then the "load tearing" issue can
> > cause similar spurious 1 -> 0 -> 1 transitions near 16-bit counter
> > overflow as described above. The "Invented
On Fri, 16 Aug 2019, Mathieu Desnoyers wrote:
> If you choose not to use READ_ONCE(), then the "load tearing" issue can
> cause similar spurious 1 -> 0 -> 1 transitions near 16-bit counter
> overflow as described above. The "Invented load" also becomes an issue,
> because the compiler could use
On Fri, 16 Aug 2019 13:41:59 -0400 (EDT)
Mathieu Desnoyers wrote:
> - On Aug 16, 2019, at 1:04 PM, rostedt rost...@goodmis.org wrote:
>
> > On Fri, 16 Aug 2019 17:48:59 +0100
> > Valentin Schneider wrote:
> >
> >> On 16/08/2019 17:25, Steven Rostedt wrote:
> >> >> Also, write and read
On Fri, 16 Aug 2019 13:19:20 -0400 (EDT)
Mathieu Desnoyers wrote:
> - On Aug 16, 2019, at 12:25 PM, rostedt rost...@goodmis.org wrote:
>
> > On Fri, 16 Aug 2019 10:26:43 -0400 Mathieu Desnoyers
> > wrote:
> >
> [...]
> >>
> >> Also, write and read to/from those variables should be
- On Aug 16, 2019, at 1:04 PM, rostedt rost...@goodmis.org wrote:
> On Fri, 16 Aug 2019 17:48:59 +0100
> Valentin Schneider wrote:
>
>> On 16/08/2019 17:25, Steven Rostedt wrote:
>> >> Also, write and read to/from those variables should be done with
>> >> WRITE_ONCE() and READ_ONCE(), given
- On Aug 16, 2019, at 12:25 PM, rostedt rost...@goodmis.org wrote:
> On Fri, 16 Aug 2019 10:26:43 -0400 Mathieu Desnoyers
> wrote:
>
[...]
>>
>> Also, write and read to/from those variables should be done with
>> WRITE_ONCE() and READ_ONCE(), given that those are read within tracing
>>
On Fri, 16 Aug 2019 17:48:59 +0100
Valentin Schneider wrote:
> On 16/08/2019 17:25, Steven Rostedt wrote:
> >> Also, write and read to/from those variables should be done with
> >> WRITE_ONCE() and READ_ONCE(), given that those are read within tracing
> >> probes without holding the
On 16/08/2019 17:25, Steven Rostedt wrote:
>> Also, write and read to/from those variables should be done with
>> WRITE_ONCE() and READ_ONCE(), given that those are read within tracing
>> probes without holding the sched_register_mutex.
>>
>
> I understand the READ_ONCE() but is the WRITE_ONCE()
On Fri, 16 Aug 2019 10:26:43 -0400
Mathieu Desnoyers wrote:
> Reading the sched_cmdline_ref and sched_tgid_ref initial state within
> tracing_start_sched_switch without holding the sched_register_mutex is
> racy against concurrent updates, which can lead to tracepoint probes
> being registered
55 matches
Mail list logo
