alignment faults in 3.6

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Fri, Oct 05, 2012 at 09:33:04AM +0100, Mans Rullgard wrote:
> On 5 October 2012 09:24, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Oct 05, 2012 at 09:20:56AM +0100, Mans Rullgard wrote:
> >> On 5 October 2012 08:12, Russell King - ARM Linux
> >> <linux@arm.linux.org.uk> wrote:
> >> > On Fri, Oct 05, 2012 at 03:25:16AM +0100, Mans Rullgard wrote:
> >> >> On 5 October 2012 02:56, Rob Herring <robherring2@gmail.com> wrote:
> >> >> > This struct is the IP header, so a struct ptr is just set to the
> >> >> > beginning of the received data. Since ethernet headers are 14 bytes,
> >> >> > often the IP header is not aligned unless the NIC can place the frame at
> >> >> > a 2 byte offset (which is something I need to investigate). So this
> >> >> > function cannot make any assumptions about the alignment. Does the ABI
> >> >> > define structs have some minimum alignment? Does the struct need to be
> >> >> > declared as packed or something?
> >> >>
> >> >> The ABI defines the alignment of structs as the maximum alignment of its
> >> >> members.  Since this struct contains 32-bit members, the alignment for the
> >> >> whole struct becomes 32 bits as well.  Declaring it as packed tells gcc it
> >> >> might be unaligned (in addition to removing any holes within).
> >> >
> >> > This has come up before in the past.
> >> >
> >> > The Linux network folk will _not_ allow - in any shape or form - for
> >> > this struct to be marked packed (it's the struct which needs to be
> >> > marked packed) because by doing so, it causes GCC to issue byte loads/
> >> > stores on architectures where there isn't a problem, and that decreases
> >> > the performance of the Linux IP stack unnecessarily.
> >>
> >> Which architectures?  I have never seen anything like that.
> >
> > Does it matter?
> 
> It matters if we want to fix it.

I can't help you there.  Ask the networking people.