On Fri 2014-09-05 12:17:16, Peter Hurley wrote:
On 09/05/2014 08:37 AM, David Laight wrote:
From: Peter Hurley
On 09/05/2014 04:30 AM, David Laight wrote:
I've seen gcc generate 32bit accesses for 16bit structure members on arm.
It does this because of the more limited range of the
On 09/14/2014 07:24 PM, One Thousand Gnomes wrote:
So a problem that no one has ever complained about on _any_ arch is suddenly
a problem on a subset of Alpha cpus, but a problem I know exists on Alpha
isn't important because no one's filed a bug about it?
Yes - because if you think about it
Yes - because if you think about it that tells you that nobody is hitting
it with the old code and it probably doesn't matter.
I don't understand this reply.
It's a matter of priorities. There are hundreds of potential security
holes turned up by scanners, 2,500+ filed bugs in kernel
On Mon, Sep 15, 2014 at 12:24:27AM +0100, One Thousand Gnomes wrote:
So a problem that no one has ever complained about on _any_ arch is suddenly
a problem on a subset of Alpha cpus, but a problem I know exists on Alpha
isn't important because no one's filed a bug about it?
Yes - because
So a problem that no one has ever complained about on _any_ arch is suddenly
a problem on a subset of Alpha cpus, but a problem I know exists on Alpha
isn't important because no one's filed a bug about it?
Yes - because if you think about it that tells you that nobody is hitting
it with the
Is *that* what we are talking about? I was added to this conversation
in the middle where it had already generalized, so I had no idea.
No, this is just what brought this craziness to my attention.
None of it is craziness. It's the real world leaking into the crazy
delusional world of
On Wed, Sep 10, 2014 at 10:48:06PM +0100, James Bottomley wrote:
On Tue, 2014-09-09 at 06:40 -0400, Peter Hurley wrote:
The processor is free to re-order this to:
STORE C
STORE B
UNLOCK
That's because the unlock() only guarantees that:
Stores before the unlock in
On Thu, Sep 11, 2014 at 11:04:11AM +0100, One Thousand Gnomes wrote:
Is *that* what we are talking about? I was added to this conversation
in the middle where it had already generalized, so I had no idea.
No, this is just what brought this craziness to my attention.
None of it is
On 09/11/2014 06:04 AM, One Thousand Gnomes wrote:
Is *that* what we are talking about? I was added to this conversation
in the middle where it had already generalized, so I had no idea.
No, this is just what brought this craziness to my attention.
None of it is craziness. It's the real
On 09/08/2014 10:52 AM, One Thousand Gnomes wrote:
I think the whole removing Alpha EV5 support is basically bonkers. Just
use set_bit in the tty layer. Alpha will continue to work as well as it
always has done and you won't design out support for any future processor
that turns out not to
On Wed, Sep 10, 2014 at 3:18 PM, H. Peter Anvin h...@zytor.com wrote:
On 09/08/2014 10:52 AM, One Thousand Gnomes wrote:
I think the whole removing Alpha EV5 support is basically bonkers. Just
use set_bit in the tty layer. Alpha will continue to work as well as it
always has done and you
On Tue, 2014-09-09 at 06:40 -0400, Peter Hurley wrote:
On 09/08/2014 10:56 PM, James Bottomley wrote:
On Mon, 2014-09-08 at 19:30 -0400, Peter Hurley wrote:
On 09/08/2014 01:50 AM, James Bottomley wrote:
But additionally, even if gcc combines adjacent writes _that are part
of the program
On 09/10/2014 05:48 PM, James Bottomley wrote:
On Tue, 2014-09-09 at 06:40 -0400, Peter Hurley wrote:
On 09/08/2014 10:56 PM, James Bottomley wrote:
On Mon, 2014-09-08 at 19:30 -0400, Peter Hurley wrote:
On 09/08/2014 01:50 AM, James Bottomley wrote:
But additionally, even if gcc combines
On Monday 08 September 2014 19:27:14 H. Peter Anvin wrote:
On 09/08/2014 03:43 PM, James Bottomley wrote:
This was years ago (possibly decades). We had to implement in-kernel
unaligned traps for the networking layer because it could access short
and int fields that weren't of the
On 09/08/2014 10:56 PM, James Bottomley wrote:
On Mon, 2014-09-08 at 19:30 -0400, Peter Hurley wrote:
On 09/08/2014 01:50 AM, James Bottomley wrote:
But additionally, even if gcc combines adjacent writes _that are part
of the program flow_ then I believe the situation is no worse than
would
On 09/08/2014 06:47 PM, Peter Hurley wrote:
On 09/08/2014 01:59 PM, H. Peter Anvin wrote:
On 09/08/2014 10:52 AM, One Thousand Gnomes wrote:
On Fri, 05 Sep 2014 08:41:52 -0700
H. Peter Anvin h...@zytor.com wrote:
On 09/05/2014 08:31 AM, Peter Hurley wrote:
Which is a bit ironic because I
On 09/08/2014 03:17 PM, One Thousand Gnomes wrote:
I think the whole removing Alpha EV5 support is basically bonkers. Just
use set_bit in the tty layer. Alpha will continue to work as well as it
always has done and you won't design out support for any future processor
that turns out not to do
Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
This commit documents the fact that it is not safe to use bitfields as
shared variables in synchronization algorithms. It also documents that
CPUs must provide
On Fri, 05 Sep 2014 08:41:52 -0700
H. Peter Anvin h...@zytor.com wrote:
On 09/05/2014 08:31 AM, Peter Hurley wrote:
Which is a bit ironic because I remember when Digital had a team
working on emulating native x86 apps on Alpha/NT.
Right, because the x86 architecture was obsolete and
On 09/08/2014 10:52 AM, One Thousand Gnomes wrote:
On Fri, 05 Sep 2014 08:41:52 -0700
H. Peter Anvin h...@zytor.com wrote:
On 09/05/2014 08:31 AM, Peter Hurley wrote:
Which is a bit ironic because I remember when Digital had a team
working on emulating native x86 apps on Alpha/NT.
On 09/07/2014 10:56 PM, James Bottomley wrote:
On Sun, 2014-09-07 at 16:39 -0700, H. Peter Anvin wrote:
How many PARISC systems do we have that actually do real work on Linux?
I'd be very surprised if this problem didn't exist on all alignment
requiring architectures, like PPC and Sparc as
On Mon, 2014-09-08 at 18:52 +0100, One Thousand Gnomes wrote:
On Fri, 05 Sep 2014 08:41:52 -0700
H. Peter Anvin h...@zytor.com wrote:
On 09/05/2014 08:31 AM, Peter Hurley wrote:
Which is a bit ironic because I remember when Digital had a team
working on emulating native x86 apps on
On Mon, 2014-09-08 at 11:12 -0700, H. Peter Anvin wrote:
On 09/07/2014 10:56 PM, James Bottomley wrote:
On Sun, 2014-09-07 at 16:39 -0700, H. Peter Anvin wrote:
How many PARISC systems do we have that actually do real work on Linux?
I'd be very surprised if this problem didn't exist on
On 09/08/2014 12:09 PM, James Bottomley wrote:
Um, I think you need to re-read the thread; that's not what I said at
all. It's even written lower down: PA can't do atomic bit sets (no
atomic RMW except the ldcw operation) it can do atomic writes to
fundamental sizes (byte, short, int, long)
I think the whole removing Alpha EV5 support is basically bonkers. Just
use set_bit in the tty layer. Alpha will continue to work as well as it
always has done and you won't design out support for any future processor
that turns out not to do byte aligned stores.
Alan
Is *that*
On 09/08/2014 12:09 PM, James Bottomley wrote:
Um, I think you need to re-read the thread; that's not what I said at
all. It's even written lower down: PA can't do atomic bit sets (no
atomic RMW except the ldcw operation) it can do atomic writes to
fundamental sizes (byte, short, int, long)
On 9/8/2014 1:50 AM, James Bottomley wrote:
Actual alignment is pretty irrelevant. That's why all architectures
which require alignment also have to implement misaligned traps ... this
is a fundamental requirement of the networking code, for instance.
Can you clarify what you think the
On Mon, 2014-09-08 at 16:45 -0400, Chris Metcalf wrote:
On 9/8/2014 1:50 AM, James Bottomley wrote:
Actual alignment is pretty irrelevant. That's why all architectures
which require alignment also have to implement misaligned traps ... this
is a fundamental requirement of the networking
On 09/08/2014 01:59 PM, H. Peter Anvin wrote:
On 09/08/2014 10:52 AM, One Thousand Gnomes wrote:
On Fri, 05 Sep 2014 08:41:52 -0700
H. Peter Anvin h...@zytor.com wrote:
On 09/05/2014 08:31 AM, Peter Hurley wrote:
Which is a bit ironic because I remember when Digital had a team
working on
On 09/08/2014 01:50 AM, James Bottomley wrote:
On Sun, 2014-09-07 at 16:41 -0400, Peter Hurley wrote:
On 09/07/2014 03:04 PM, James Bottomley wrote:
On Sun, 2014-09-07 at 09:21 -0700, Paul E. McKenney wrote:
On Sat, Sep 06, 2014 at 10:07:22PM -0700, James Bottomley wrote:
On Thu, 2014-09-04
On Mon, Sep 08, 2014 at 06:47:35PM -0400, Peter Hurley wrote:
On 09/08/2014 01:59 PM, H. Peter Anvin wrote:
On 09/08/2014 10:52 AM, One Thousand Gnomes wrote:
On Fri, 05 Sep 2014 08:41:52 -0700
H. Peter Anvin h...@zytor.com wrote:
On 09/05/2014 08:31 AM, Peter Hurley wrote:
Which is
On 09/08/2014 03:43 PM, James Bottomley wrote:
This was years ago (possibly decades). We had to implement in-kernel
unaligned traps for the networking layer because it could access short
and int fields that weren't of the correct alignment when processing
packets. It that's all corrected
On Mon, 2014-09-08 at 19:30 -0400, Peter Hurley wrote:
On 09/08/2014 01:50 AM, James Bottomley wrote:
Two things: I think that gcc has given up on combining adjacent writes,
perhaps because unaligned writes on some arches are prohibitive, so
whatever minor optimization was believed to be
On 09/08/2014 07:56 PM, James Bottomley wrote:
Yeah, the extra requirement I added is basically nonsense, since the
only issue is what instructions the compiler is emitting. So if compiler
thinks the alignment is natural and combines the writes -- ok. If the
compiler thinks the alignment is
Add a short member for proper alignment and one will probably pop out.
Sent from my tablet, pardon any formatting problems.
On Sep 8, 2014, at 19:56, James Bottomley
james.bottom...@hansenpartnership.com wrote:
On Mon, 2014-09-08 at 19:30 -0400, Peter Hurley wrote:
On 09/08/2014 01:50 AM,
On Sat, Sep 06, 2014 at 10:07:22PM -0700, James Bottomley wrote:
On Thu, 2014-09-04 at 21:06 -0700, Paul E. McKenney wrote:
On Thu, Sep 04, 2014 at 10:47:24PM -0400, Peter Hurley wrote:
Hi James,
On 09/04/2014 10:11 PM, James Bottomley wrote:
On Thu, 2014-09-04 at 17:17 -0700,
On Sun, 2014-09-07 at 09:21 -0700, Paul E. McKenney wrote:
On Sat, Sep 06, 2014 at 10:07:22PM -0700, James Bottomley wrote:
On Thu, 2014-09-04 at 21:06 -0700, Paul E. McKenney wrote:
On Thu, Sep 04, 2014 at 10:47:24PM -0400, Peter Hurley wrote:
Hi James,
On 09/04/2014 10:11 PM,
On 09/07/2014 03:04 PM, James Bottomley wrote:
On Sun, 2014-09-07 at 09:21 -0700, Paul E. McKenney wrote:
On Sat, Sep 06, 2014 at 10:07:22PM -0700, James Bottomley wrote:
On Thu, 2014-09-04 at 21:06 -0700, Paul E. McKenney wrote:
On Thu, Sep 04, 2014 at 10:47:24PM -0400, Peter Hurley wrote:
On Sun, Sep 07, 2014 at 12:04:47PM -0700, James Bottomley wrote:
On Sun, 2014-09-07 at 09:21 -0700, Paul E. McKenney wrote:
On Sat, Sep 06, 2014 at 10:07:22PM -0700, James Bottomley wrote:
On Thu, 2014-09-04 at 21:06 -0700, Paul E. McKenney wrote:
On Thu, Sep 04, 2014 at 10:47:24PM
I'm confused why storing 0x0102 would be a problem. I think gcc does that even
on other cpus.
More atomicity can't hurt, can it?
On September 7, 2014 4:00:19 PM PDT, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
On Sun, Sep 07, 2014 at 12:04:47PM -0700, James Bottomley wrote:
On Sun,
On Sun, Sep 07, 2014 at 04:17:30PM -0700, H. Peter Anvin wrote:
I'm confused why storing 0x0102 would be a problem. I think gcc does that
even on other cpus.
More atomicity can't hurt, can it?
I must defer to James for any additional details on why PARISC systems
don't provide atomicity
How many PARISC systems do we have that actually do real work on Linux?
On September 7, 2014 4:36:55 PM PDT, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
On Sun, Sep 07, 2014 at 04:17:30PM -0700, H. Peter Anvin wrote:
I'm confused why storing 0x0102 would be a problem. I think gcc does
On Sun, 2014-09-07 at 16:41 -0400, Peter Hurley wrote:
On 09/07/2014 03:04 PM, James Bottomley wrote:
On Sun, 2014-09-07 at 09:21 -0700, Paul E. McKenney wrote:
On Sat, Sep 06, 2014 at 10:07:22PM -0700, James Bottomley wrote:
On Thu, 2014-09-04 at 21:06 -0700, Paul E. McKenney wrote:
On
On Sun, 2014-09-07 at 16:39 -0700, H. Peter Anvin wrote:
How many PARISC systems do we have that actually do real work on Linux?
I'd be very surprised if this problem didn't exist on all alignment
requiring architectures, like PPC and Sparc as well. I know it would be
very convenient if all the
On Thu, 2014-09-04 at 21:06 -0700, Paul E. McKenney wrote:
On Thu, Sep 04, 2014 at 10:47:24PM -0400, Peter Hurley wrote:
Hi James,
On 09/04/2014 10:11 PM, James Bottomley wrote:
On Thu, 2014-09-04 at 17:17 -0700, Paul E. McKenney wrote:
+And there are anti-guarantees:
+
+ (*)
From: Paul E. McKenney
On Thu, Sep 04, 2014 at 10:47:24PM -0400, Peter Hurley wrote:
Hi James,
On 09/04/2014 10:11 PM, James Bottomley wrote:
On Thu, 2014-09-04 at 17:17 -0700, Paul E. McKenney wrote:
+And there are anti-guarantees:
+
+ (*) These guarantees do not apply to
On Thu, Sep 04, 2014 at 07:08:48PM -0700, H. Peter Anvin wrote:
On 09/04/2014 05:59 PM, Peter Hurley wrote:
I have no idea how prevalent the ev56 is compared to the ev5.
Still we're talking about a chip that came out in 1996.
Ah yes, I stand corrected. According to Wikipedia, the affected
[ +cc linux-arm ]
Hi David,
On 09/05/2014 04:30 AM, David Laight wrote:
I've seen gcc generate 32bit accesses for 16bit structure members on arm.
It does this because of the more limited range of the offsets for the 16bit
access.
OTOH I don't know if it ever did this for writes - so it may
From: Peter Hurley
[ +cc linux-arm ]
Hi David,
On 09/05/2014 04:30 AM, David Laight wrote:
I've seen gcc generate 32bit accesses for 16bit structure members on arm.
It does this because of the more limited range of the offsets for the 16bit
access.
OTOH I don't know if it ever did
On 09/04/2014 10:08 PM, H. Peter Anvin wrote:
On 09/04/2014 05:59 PM, Peter Hurley wrote:
I have no idea how prevalent the ev56 is compared to the ev5.
Still we're talking about a chip that came out in 1996.
Ah yes, I stand corrected. According to Wikipedia, the affected CPUs
were all the
On 09/05/2014 08:31 AM, Peter Hurley wrote:
Which is a bit ironic because I remember when Digital had a team
working on emulating native x86 apps on Alpha/NT.
Right, because the x86 architecture was obsolete and would never scale...
-hpa
On 09/05/2014 08:37 AM, David Laight wrote:
From: Peter Hurley
On 09/05/2014 04:30 AM, David Laight wrote:
I've seen gcc generate 32bit accesses for 16bit structure members on arm.
It does this because of the more limited range of the offsets for the 16bit
access.
OTOH I don't know if it
On Fri, Sep 05, 2014 at 08:16:48PM +1200, Michael Cree wrote:
On Thu, Sep 04, 2014 at 07:08:48PM -0700, H. Peter Anvin wrote:
On 09/04/2014 05:59 PM, Peter Hurley wrote:
I have no idea how prevalent the ev56 is compared to the ev5.
Still we're talking about a chip that came out in 1996.
On Fri, Sep 05, 2014 at 11:09:50AM -0700, Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 08:16:48PM +1200, Michael Cree wrote:
On Thu, Sep 04, 2014 at 07:08:48PM -0700, H. Peter Anvin wrote:
On 09/04/2014 05:59 PM, Peter Hurley wrote:
I have no idea how prevalent the ev56 is compared to
On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 08:16:48PM +1200, Michael Cree wrote:
On Thu, Sep 04, 2014 at 07:08:48PM -0700, H. Peter Anvin wrote:
On 09/04/2014 05:59 PM, Peter Hurley wrote:
I have no idea how prevalent the ev56 is compared to the ev5.
Still we're
On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 08:16:48PM +1200, Michael Cree wrote:
On Thu, Sep 04, 2014 at 07:08:48PM -0700, H. Peter Anvin wrote:
On 09/04/2014 05:59 PM, Peter Hurley wrote:
I have no
On 09/05/2014 03:05 PM, Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
[cut]
documentation: Record limitations of bitfields and
On Fri, Sep 05, 2014 at 11:31:09AM -0700, Paul E. McKenney wrote:
compiler: Allow 1- and 2-byte smp_load_acquire() and smp_store_release()
CPUs without single-byte and double-byte loads and stores place some
interesting requirements on concurrent code. For example (adapted
from Peter
On 09/05/2014 03:52 PM, Peter Zijlstra wrote:
On Fri, Sep 05, 2014 at 11:31:09AM -0700, Paul E. McKenney wrote:
compiler: Allow 1- and 2-byte smp_load_acquire() and smp_store_release()
CPUs without single-byte and double-byte loads and stores place some
interesting requirements on concurrent
On Fri, Sep 05, 2014 at 03:24:35PM -0400, Peter Hurley wrote:
On 09/05/2014 03:05 PM, Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
[cut]
On 09/05/2014 03:38 PM, Marc Gauthier wrote:
Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
This commit documents the fact that it is not safe to use bitfields as
shared variables in synchronization
On 09/05/2014 01:12 PM, Peter Zijlstra wrote:
... and I'm wondering if I should _remove_ pre-EV56 configurations or
move the default choice and produce a warning about unsupported Alpha
CPUs instead?
depends BROKEN
or is that deprecated?
Just rip it out, like I did for the i386.
On Fri, Sep 05, 2014 at 04:01:35PM -0400, Peter Hurley wrote:
On 09/05/2014 03:52 PM, Peter Zijlstra wrote:
On Fri, Sep 05, 2014 at 11:31:09AM -0700, Paul E. McKenney wrote:
compiler: Allow 1- and 2-byte smp_load_acquire() and smp_store_release()
CPUs without single-byte and double-byte
On 09/05/2014 01:14 PM, Peter Hurley wrote:
Here's how I read the two statements.
First, the commit message:
It [this commit] documents that CPUs [supported by the Linux kernel]
_must provide_ atomic one-byte and two-byte naturally aligned loads and
stores.
Second, in the body of
On Fri, Sep 05, 2014 at 04:14:48PM -0400, Peter Hurley wrote:
Second, in the body of the document:
The Linux kernel no longer supports pre-EV56 Alpha CPUs, because these
older CPUs _do not provide_ atomic one-byte and two-byte loads and stores.
Let's be clear here, the pre-EV56 Alpha CPUs do
On Fri, Sep 05, 2014 at 04:14:48PM -0400, Peter Hurley wrote:
On 09/05/2014 03:38 PM, Marc Gauthier wrote:
Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
This commit documents the fact that it is not
On Fri, Sep 05, 2014 at 01:34:52PM -0700, H. Peter Anvin wrote:
On 09/05/2014 01:14 PM, Peter Hurley wrote:
Here's how I read the two statements.
First, the commit message:
It [this commit] documents that CPUs [supported by the Linux kernel]
_must provide_ atomic one-byte and
On Fri, Sep 05, 2014 at 01:34:52PM -0700, H. Peter Anvin wrote:
On 09/05/2014 01:14 PM, Peter Hurley wrote:
Here's how I read the two statements.
First, the commit message:
It [this commit] documents that CPUs [supported by the Linux kernel]
_must provide_ atomic one-byte and
On Fri, 5 Sep 2014, Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 01:34:52PM -0700, H. Peter Anvin wrote:
On 09/05/2014 01:14 PM, Peter Hurley wrote:
Here's how I read the two statements.
First, the commit message:
It [this commit] documents that CPUs [supported by the
On Fri, Sep 05, 2014 at 10:48:34PM +0200, Thomas Gleixner wrote:
On Fri, 5 Sep 2014, Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 01:34:52PM -0700, H. Peter Anvin wrote:
On 09/05/2014 01:14 PM, Peter Hurley wrote:
Here's how I read the two statements.
First, the commit
On 09/05/2014 04:39 PM, Michael Cree wrote:
On Fri, Sep 05, 2014 at 04:14:48PM -0400, Peter Hurley wrote:
Second, in the body of the document:
The Linux kernel no longer supports pre-EV56 Alpha CPUs, because these
older CPUs _do not provide_ atomic one-byte and two-byte loads and stores.
On Fri, Sep 05, 2014 at 05:12:28PM -0400, Peter Hurley wrote:
On 09/05/2014 04:39 PM, Michael Cree wrote:
On Fri, Sep 05, 2014 at 04:14:48PM -0400, Peter Hurley wrote:
Second, in the body of the document:
The Linux kernel no longer supports pre-EV56 Alpha CPUs, because these
older CPUs
From: Benjamin Herrenschmidt
On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote:
Apologies for hijacking this thread but I need to extend this discussion
somewhat regarding what a compiler might do with adjacent fields in a
structure.
The tty subsystem defines a large aggregate
On Thu, Sep 04, 2014 at 10:57:40AM +0200, Mikael Pettersson wrote:
Benjamin Herrenschmidt writes:
On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote:
Apologies for hijacking this thread but I need to extend this discussion
somewhat regarding what a compiler might do with
On Thu, 2014-09-04 at 08:43 +, David Laight wrote:
From: Benjamin Herrenschmidt
On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote:
Apologies for hijacking this thread but I need to extend this discussion
somewhat regarding what a compiler might do with adjacent fields in a
On 09/04/2014 05:09 AM, Jakub Jelinek wrote:
On Thu, Sep 04, 2014 at 10:57:40AM +0200, Mikael Pettersson wrote:
Benjamin Herrenschmidt writes:
On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote:
Apologies for hijacking this thread but I need to extend this discussion
somewhat
On Thu, Sep 04, 2014 at 08:24:12AM -0400, Peter Hurley wrote:
And I just confirmed with the Alpha cross-compiler that the fields are
not 'padded out' if volatile either.
They can't be, struct layout is part of the ABI.
Guess you can introduce say atomic_bool and similar typedefs which would be
Benjamin Herrenschmidt writes:
On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote:
Apologies for hijacking this thread but I need to extend this discussion
somewhat regarding what a compiler might do with adjacent fields in a
structure.
The tty subsystem defines a large
Besides updating the documentation, it may make sense to do something
arch-specific. Just bumping out storage on arches that don't need it
seems wasteful, as does generating bus locks on arches that don't need it.
Unfortunately, the code churn looks unavoidable.
The arch specific is pretty
On 09/04/2014 12:50 PM, One Thousand Gnomes wrote:
Besides updating the documentation, it may make sense to do something
arch-specific. Just bumping out storage on arches that don't need it
seems wasteful, as does generating bus locks on arches that don't need it.
Unfortunately, the code churn
On 09/04/2014 02:52 AM, Benjamin Herrenschmidt wrote:
Yeah correct, alpha and bytes right ? Is there any other ? That's why I
suggested int.
Even for Alpha it is only the 21064 AFAIK.
-hpa
___
Linuxppc-dev mailing list
On 09/04/2014 12:42 PM, Peter Hurley wrote:
Or we could give up on the Alpha.
If Alpha is turning into Voyager (kept alive only as a museum piece, but
actively causing problems) then please let's kill it.
-hpa
___
Linuxppc-dev mailing
On Thu, Sep 04, 2014 at 03:16:03PM -0700, H. Peter Anvin wrote:
On 09/04/2014 12:42 PM, Peter Hurley wrote:
Or we could give up on the Alpha.
If Alpha is turning into Voyager (kept alive only as a museum piece, but
actively causing problems) then please let's kill it.
Sorry for being
[ +cc linux-alpha ]
On 09/04/2014 06:14 PM, H. Peter Anvin wrote:
On 09/04/2014 02:52 AM, Benjamin Herrenschmidt wrote:
Yeah correct, alpha and bytes right ? Is there any other ? That's why I
suggested int.
Even for Alpha it is only the 21064 AFAIK.
For -mcpu=ev5 (21164) and the
[ +cc linux-alpha ]
Hi Paul,
On 09/04/2014 08:17 PM, Paul E. McKenney wrote:
On Thu, Sep 04, 2014 at 03:16:03PM -0700, H. Peter Anvin wrote:
On 09/04/2014 12:42 PM, Peter Hurley wrote:
Or we could give up on the Alpha.
If Alpha is turning into Voyager (kept alive only as a museum piece,
On 09/04/2014 05:59 PM, Peter Hurley wrote:
I have no idea how prevalent the ev56 is compared to the ev5.
Still we're talking about a chip that came out in 1996.
Ah yes, I stand corrected. According to Wikipedia, the affected CPUs
were all the 2106x CPUs (EV4, EV45, LCA4, LCA45) plus the 21164
On 09/04/2014 05:59 PM, Peter Hurley wrote:
I have no idea how prevalent the ev56 is compared to the ev5.
Still we're talking about a chip that came out in 1996.
Ah yes, I stand corrected. According to Wikipedia, the affected CPUs
were all the 2106x CPUs (EV4, EV45, LCA4, LCA45) plus the 21164
On Thu, 2014-09-04 at 17:17 -0700, Paul E. McKenney wrote:
+And there are anti-guarantees:
+
+ (*) These guarantees do not apply to bitfields, because compilers often
+ generate code to modify these using non-atomic read-modify-write
+ sequences. Do not attempt to use bitfields to
Hi James,
On 09/04/2014 10:11 PM, James Bottomley wrote:
On Thu, 2014-09-04 at 17:17 -0700, Paul E. McKenney wrote:
+And there are anti-guarantees:
+
+ (*) These guarantees do not apply to bitfields, because compilers often
+ generate code to modify these using non-atomic
On Thu, Sep 04, 2014 at 10:47:24PM -0400, Peter Hurley wrote:
Hi James,
On 09/04/2014 10:11 PM, James Bottomley wrote:
On Thu, 2014-09-04 at 17:17 -0700, Paul E. McKenney wrote:
+And there are anti-guarantees:
+
+ (*) These guarantees do not apply to bitfields, because compilers often
On Wed, 2014-09-03 at 18:51 -0400, Peter Hurley wrote:
Apologies for hijacking this thread but I need to extend this discussion
somewhat regarding what a compiler might do with adjacent fields in a
structure.
The tty subsystem defines a large aggregate structure, struct tty_struct.
[ +cc linux-arch, Tony Luck,
On 07/12/2014 02:13 PM, Oleg Nesterov wrote:
Hello,
I am not sure I should ask here, but since Documentation/memory-barriers.txt
mentions load/store tearing perhaps my question is not completely off-topic...
I am fighting with mysterious RHEL bug, it can be
On 07/13/2014 06:25 PM, Benjamin Herrenschmidt wrote:
On Sun, 2014-07-13 at 09:15 -0400, Peter Hurley wrote:
I'm not sure I understand your point here, Ben.
Suppose that two different spinlocks are used independently to
protect r-m-w access to adjacent data. In Oleg's example,
suppose
On 07/15/2014 06:54 AM, Peter Hurley wrote:
Jonathan Corbet wrote a LWN article about this back in 2012:
http://lwn.net/Articles/478657/
I guess it's fixed in gcc 4.8, but too bad there's not a workaround for
earlier compilers (akin to -fstrict_volatile_bitfields without requiring
the
On 07/13, Benjamin Herrenschmidt wrote:
On Sat, 2014-07-12 at 22:51 +0200, Oleg Nesterov wrote:
OK, looks like this is compiler bug,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080
Thanks to Dan who informed me privately.
So yes, there's is this compiler bug which means a bitfield
On 07/12/2014 07:34 PM, Benjamin Herrenschmidt wrote:
On Sat, 2014-07-12 at 22:51 +0200, Oleg Nesterov wrote:
OK, looks like this is compiler bug,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080
Thanks to Dan who informed me privately.
So yes, there's is this compiler bug which means a
On Sun, 2014-07-13 at 09:15 -0400, Peter Hurley wrote:
I'm not sure I understand your point here, Ben.
Suppose that two different spinlocks are used independently to
protect r-m-w access to adjacent data. In Oleg's example,
suppose spinlock 1 is used for access to the bitfield and
OK, looks like this is compiler bug,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080
Thanks to Dan who informed me privately.
On 07/12, Oleg Nesterov wrote:
Hello,
I am not sure I should ask here, but since Documentation/memory-barriers.txt
mentions load/store tearing perhaps my
On Sat, 2014-07-12 at 22:51 +0200, Oleg Nesterov wrote:
OK, looks like this is compiler bug,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080
Thanks to Dan who informed me privately.
So yes, there's is this compiler bug which means a bitfield
access can cause a r-m-w access to a
99 matches
Mail list logo
