> > > Also I'd be surprised if ppc64 is the only one with that problem... what
> > > about sparc64 and arm64 ?
> >
> > Even x86 could be affected.
> > The width of the memory cycles used by the 'bit set and bit clear'
> > instructions isn't documented. They are certainly allowed to do
> > RMW on ad
On Fri, 2013-05-03 at 15:29 +0100, David Laight wrote:
> > > Could ppc64 experts confirm using byte is safe, or should we really add
> > > a 32bit hole after the spinlock ? If so, I wonder how many other places
> > > need a change...
> ...
> > Also I'd be surprised if ppc64 is the only one with tha
> > Could ppc64 experts confirm using byte is safe, or should we really add
> > a 32bit hole after the spinlock ? If so, I wonder how many other places
> > need a change...
...
> Also I'd be surprised if ppc64 is the only one with that problem... what
> about sparc64 and arm64 ?
Even x86 could be
On Fri, 2013-05-03 at 11:01 +0930, Alan Modra wrote:
> On Tue, Apr 30, 2013 at 10:04:32PM -0700, Eric Dumazet wrote:
> > These kind of errors are pretty hard to find, its a pity to spend time
> > on them.
>
> Well, yes. From the first comment in gcc PR52080. "For the following
> testcase we gene
On Fri, 2013-05-03 at 11:01 +0930, Alan Modra wrote:
> On Tue, Apr 30, 2013 at 10:04:32PM -0700, Eric Dumazet wrote:
> > These kind of errors are pretty hard to find, its a pity to spend time
> > on them.
>
> Well, yes. From the first comment in gcc PR52080. "For the following
> testcase we gene
> Did someone fix btrfs, but not check other kernel locks? Having now
> hit the same problem again, have you checked that other kernel locks
> don't have adjacent bit fields in the same 64-bit word? And comment
> the struct to ensure someone doesn't optimize those unsigned chars
> back to bit fie
On Tue, Apr 30, 2013 at 10:04:32PM -0700, Eric Dumazet wrote:
> These kind of errors are pretty hard to find, its a pity to spend time
> on them.
Well, yes. From the first comment in gcc PR52080. "For the following
testcase we generate a 8 byte RMW cycle on IA64 which causes locking
problems in
On Wed, 2013-05-01 at 08:10 -0700, Stephen Hemminger wrote:
> > These kind of errors are pretty hard to find, its a pity to spend
> time
> > on them.
>
> There is a checkbin target inside arch/powerpc/Makefile
> Shouldn't a check be added there to block building kernel with known
> bad GCC version
On 04/30/2013 10:54:25 PM, Alan Modra wrote:
On Tue, Apr 30, 2013 at 07:24:20PM -0700, Eric Dumazet wrote:
>li 11,1
>ld 0,0(9)
>rldimi 0,11,31,32
>std 0,0(9)
>blr
>.ident "GCC: (GNU) 4.6.3"
>
> You can see "ld 0,0(9)" is used : its a 64 bit load.
Yup. This is not a powe
On Tue, 30 Apr 2013 22:04:32 -0700
Eric Dumazet wrote:
> On Wed, 2013-05-01 at 13:24 +0930, Alan Modra wrote:
> > On Tue, Apr 30, 2013 at 07:24:20PM -0700, Eric Dumazet wrote:
> > > li 11,1
> > > ld 0,0(9)
> > > rldimi 0,11,31,32
> > > std 0,0(9)
> > > blr
> > > .ident "GCC: (GNU) 4.
On Wed, 2013-05-01 at 11:39 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2013-04-30 at 18:12 -0700, Eric Dumazet wrote:
> > From: Eric Dumazet
> >
> > Using bit fields is dangerous on ppc64, as the compiler uses 64bit
> > instructions to manipulate them. If the 64bit word includes any
> > atomi
On Wed, 2013-05-01 at 03:36 -0400, David Miller wrote:
> From: Benjamin Herrenschmidt
> Date: Wed, 01 May 2013 11:39:53 +1000
>
> > I'm not even completely certain bytes are safe to be honest, though
> > probably more than bitfields. I'll poke our compiler people.
>
> Older Alpha only has 32-bit
From: Benjamin Herrenschmidt
Date: Wed, 01 May 2013 11:39:53 +1000
> I'm not even completely certain bytes are safe to be honest, though
> probably more than bitfields. I'll poke our compiler people.
Older Alpha only has 32-bit and 64-bit loads and stores, so byte sized
accesses are not atomic,
On Wed, 2013-05-01 at 13:24 +0930, Alan Modra wrote:
> On Tue, Apr 30, 2013 at 07:24:20PM -0700, Eric Dumazet wrote:
> > li 11,1
> > ld 0,0(9)
> > rldimi 0,11,31,32
> > std 0,0(9)
> > blr
> > .ident "GCC: (GNU) 4.6.3"
> >
> > You can see "ld 0,0(9)" is used : its a 64 bit
On Tue, Apr 30, 2013 at 07:24:20PM -0700, Eric Dumazet wrote:
> li 11,1
> ld 0,0(9)
> rldimi 0,11,31,32
> std 0,0(9)
> blr
> .ident "GCC: (GNU) 4.6.3"
>
> You can see "ld 0,0(9)" is used : its a 64 bit load.
Yup. This is not a powerpc64 specific problem. See
On Wed, 2013-05-01 at 11:51 +1000, Anton Blanchard wrote:
> Hi Eric,
>
> > From: Eric Dumazet
> >
> > Using bit fields is dangerous on ppc64, as the compiler uses 64bit
> > instructions to manipulate them. If the 64bit word includes any
> > atomic_t or spinlock_t, we can lose critical concurrent
Hi Eric,
> From: Eric Dumazet
>
> Using bit fields is dangerous on ppc64, as the compiler uses 64bit
> instructions to manipulate them. If the 64bit word includes any
> atomic_t or spinlock_t, we can lose critical concurrent changes.
>
> This is happening in af_unix, where unix_sk(sk)->gc_candi
On Tue, 2013-04-30 at 18:12 -0700, Eric Dumazet wrote:
> From: Eric Dumazet
>
> Using bit fields is dangerous on ppc64, as the compiler uses 64bit
> instructions to manipulate them. If the 64bit word includes any
> atomic_t or spinlock_t, we can lose critical concurrent changes.
>
> This is happ
18 matches
Mail list logo
