On Wed, 1 Dec 2010 22:11:53 +0000 Will Newton <[email protected]> wrote:

> The current packed struct implementation of unaligned access adds
> the packed attribute only to the field within the unaligned struct
> rather than to the struct as a whole. This is not sufficient to
> enforce proper behaviour on architectures with a default struct
> alignment of more than one byte.
> 
> For example, the current implementation of __get_unaligned_cpu16
> when compiled for arm with gcc -O1 -mstructure-size-boundary=32
> assumes the struct is on a 4 byte boundary so performs the load
> of the 16bit packed field as if it were on a 4 byte boundary:
> 
> __get_unaligned_cpu16:
>         ldrh    r0, [r0, #0]
>         bx      lr
> 
> Moving the packed attribute to the struct rather than the field
> causes the proper unaligned access code to be generated:
> 
> __get_unaligned_cpu16:
>       ldrb    r3, [r0, #0]    @ zero_extendqisi2
>       ldrb    r0, [r0, #1]    @ zero_extendqisi2
>       orr     r0, r3, r0, asl #8
>       bx      lr
> 
> Signed-off-by: Will Newton <[email protected]>
> ---
>  include/linux/unaligned/packed_struct.h |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/unaligned/packed_struct.h
> b/include/linux/unaligned/packed_struct.h
> index 2498bb9..c9a6abd 100644
> --- a/include/linux/unaligned/packed_struct.h
> +++ b/include/linux/unaligned/packed_struct.h
> @@ -3,9 +3,9 @@
> 
>  #include <linux/kernel.h>
> 
> -struct __una_u16 { u16 x __attribute__((packed)); };
> -struct __una_u32 { u32 x __attribute__((packed)); };
> -struct __una_u64 { u64 x __attribute__((packed)); };
> +struct __una_u16 { u16 x; } __attribute__((packed));
> +struct __una_u32 { u32 x; } __attribute__((packed));
> +struct __una_u64 { u64 x; } __attribute__((packed));
> 

Yes, that was wrong.

Do you think this bug affects 2.6.36 or earlier?

Even if it doesn't, it looks like a bit of a hand-grenade to leave it
unfixed in earlier kernels.

_______________________________________________
stable mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/stable

Reply via email to