reorganized struct inode results in unaligned accesses

reorganized struct inode results in unaligned accesses

[Meelis Roos]

A week ago I noticed that in 3.0.0-rc3, sparc64 machines log a lot of 
unaligned accesses in different vfs functions in dmesg. I reported but 
obviously not well enough. Today I had a look at it and found the 
reason.

Commit 13e12d14e2dccc7995b8f15a5678a338ab4e6a8c (vfs: reorganize 'struct 
inode' layout a bit) changes i_state to be unsigned int instead of 
unsigned long. This is the cause of unaligned accesses on sparc64 and 
maybe others. Changing it back to unsigned long fixes the warnings but I 
did not look at the layout of the resulting struct - might leave a hole 
there.

-- 
Meelis Roos (mroos@linux.ee)

reorganized struct inode results in unaligned accesses

[Meelis Roos]

A week ago I noticed that in 3.0.0-rc3, sparc64 machines log a lot of 
unaligned accesses in different vfs functions in dmesg. I reported but 
obviously not well enough. Today I had a look at it and found the 
reason.

Commit 13e12d14e2dccc7995b8f15a5678a338ab4e6a8c (vfs: reorganize 'struct 
inode' layout a bit) changes i_state to be unsigned int instead of 
unsigned long. This is the cause of unaligned accesses on sparc64 and 
maybe others. Changing it back to unsigned long fixes the warnings but I 
did not look at the layout of the resulting struct - might leave a hole 
there.

-- 
Meelis Roos (mroos@linux.ee)

Re: reorganized struct inode results in unaligned accesses

[Linus Torvalds]

On Sun, Jun 19, 2011 at 9:33 AM, Meelis Roos <mroos@linux.ee> wrote:
>
> Commit 13e12d14e2dccc7995b8f15a5678a338ab4e6a8c (vfs: reorganize 'struct
> inode' layout a bit) changes i_state to be unsigned int instead of
> unsigned long. This is the cause of unaligned accesses on sparc64 and
> maybe others. Changing it back to unsigned long fixes the warnings but I
> did not look at the layout of the resulting struct - might leave a hole
> there.

Argh. Gaah, we acces that thing with the bit-ops when we do the
bit_waitqueue() and wait_on_bit() thing.

My bad, and apparently our type checking for the wait-on-bit stuff
isn't as tight as it should be.

Dang. I guess it needs to be made "unsigned long" again. Which is a
shame, because we only use a couple of bits from there, and "struct
inode" really is much too big already.

I do wonder why "wait_on_bit()" takes a "void *", when apparently it
can only handle "unsigned long *" entities. Maybe we could fix the
implementation to really take anything.

                  Linus

Re: reorganized struct inode results in unaligned accesses

[Linus Torvalds]

On Sun, Jun 19, 2011 at 9:33 AM, Meelis Roos <mroos@linux.ee> wrote:
>
> Commit 13e12d14e2dccc7995b8f15a5678a338ab4e6a8c (vfs: reorganize 'struct
> inode' layout a bit) changes i_state to be unsigned int instead of
> unsigned long. This is the cause of unaligned accesses on sparc64 and
> maybe others. Changing it back to unsigned long fixes the warnings but I
> did not look at the layout of the resulting struct - might leave a hole
> there.

Argh. Gaah, we acces that thing with the bit-ops when we do the
bit_waitqueue() and wait_on_bit() thing.

My bad, and apparently our type checking for the wait-on-bit stuff
isn't as tight as it should be.

Dang. I guess it needs to be made "unsigned long" again. Which is a
shame, because we only use a couple of bits from there, and "struct
inode" really is much too big already.

I do wonder why "wait_on_bit()" takes a "void *", when apparently it
can only handle "unsigned long *" entities. Maybe we could fix the
implementation to really take anything.

                  Linus

Re: reorganized struct inode results in unaligned accesses

[Andi Kleen]

Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> Dang. I guess it needs to be made "unsigned long" again. Which is a
> shame, because we only use a couple of bits from there, and "struct
> inode" really is much too big already.

In the past it was usually enough to just align it to alignof(unsigned
long), not actually make it long. struct page went through this
a long time ago.

This could cause r-m-w races with the next field in theory, but assuming
it's reasonably read-only (ie only set up at inode creation time)
that should be fine.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only

Re: reorganized struct inode results in unaligned accesses

[Andi Kleen]

Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> Dang. I guess it needs to be made "unsigned long" again. Which is a
> shame, because we only use a couple of bits from there, and "struct
> inode" really is much too big already.

In the past it was usually enough to just align it to alignof(unsigned
long), not actually make it long. struct page went through this
a long time ago.

This could cause r-m-w races with the next field in theory, but assuming
it's reasonably read-only (ie only set up at inode creation time)
that should be fine.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only

Re: reorganized struct inode results in unaligned accesses

[David Miller]

From: Andi Kleen <andi@firstfloor.org>
Date: Sun, 19 Jun 2011 15:35:30 -0700

> Linus Torvalds <torvalds@linux-foundation.org> writes:
>>
>> Dang. I guess it needs to be made "unsigned long" again. Which is a
>> shame, because we only use a couple of bits from there, and "struct
>> inode" really is much too big already.
> 
> In the past it was usually enough to just align it to alignof(unsigned
> long), not actually make it long. struct page went through this
> a long time ago.

Hmmm, can this scheme actually work out properly on both big and
little endian?  Because endianness determines whether the bits start
in the "lower addressed" 32-bit word or the "higher addressed" 32-bit
word.

If this trick is being attempted elsewhere, I think it could perhaps
account for some strange bugs :-)

Re: reorganized struct inode results in unaligned accesses

[David Miller]

From: Andi Kleen <andi@firstfloor.org>
Date: Sun, 19 Jun 2011 15:35:30 -0700

> Linus Torvalds <torvalds@linux-foundation.org> writes:
>>
>> Dang. I guess it needs to be made "unsigned long" again. Which is a
>> shame, because we only use a couple of bits from there, and "struct
>> inode" really is much too big already.
> 
> In the past it was usually enough to just align it to alignof(unsigned
> long), not actually make it long. struct page went through this
> a long time ago.

Hmmm, can this scheme actually work out properly on both big and
little endian?  Because endianness determines whether the bits start
in the "lower addressed" 32-bit word or the "higher addressed" 32-bit
word.

If this trick is being attempted elsewhere, I think it could perhaps
account for some strange bugs :-)

Re: reorganized struct inode results in unaligned accesses

[Andi Kleen]

> Hmmm, can this scheme actually work out properly on both big and
> little endian?  Because endianness determines whether the bits start
> in the "lower addressed" 32-bit word or the "higher addressed" 32-bit
> word.

True, it needs an ifdef, with the other order in BE. struct page has that iirc.

> 
> If this trick is being attempted elsewhere, I think it could perhaps
> account for some strange bugs :-)

Well if you want to be sure better try to get rid of the void *

(I tried early on in x86-64, it caused a lot of warnings all over)

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

Re: reorganized struct inode results in unaligned accesses

[Andi Kleen]

> Hmmm, can this scheme actually work out properly on both big and
> little endian?  Because endianness determines whether the bits start
> in the "lower addressed" 32-bit word or the "higher addressed" 32-bit
> word.

True, it needs an ifdef, with the other order in BE. struct page has that iirc.

> 
> If this trick is being attempted elsewhere, I think it could perhaps
> account for some strange bugs :-)

Well if you want to be sure better try to get rid of the void *

(I tried early on in x86-64, it caused a lot of warnings all over)

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.