Re: [RFC] net/hsr: Add support for IEC 62439-3 High-availability Seamless Redundancy

On Fri, 6 Apr 2012 18:06:31 +0100
Ben Hutchings [off-list ref] wrote:

On Fri, 2012-04-06 at 17:51 +0200, Arvid Brodin wrote:

quoted

David Miller wrote:

quoted

From: Stephen Hemminger <redacted>
Date: Wed, 4 Apr 2012 16:55:59 -0700

quoted

That isn't so bad, doing a memcpy versus a structure copy.

GCC is going to inline the memcpy and thus we'll still do the
unaligned accesses.  This change therefore won't fix the problem.

Well, it does work for me, with gcc-4.2.2-compiled linux-2.6.37 running
on an AVR32 board.

Just out of curiosity, what's the mechanism behind this inline
assignment that turns the memcpy into an unaligned access? If gcc is 
"smart" enough to detect a bunch of char * accesses and turn them 
into unaligned 32-bit accesses, isn't that a bug in gcc?

If I remember correctly, casting a char* pointer to foo* where the
original pointer isn't properly aligned for type foo results in
undefined behaviour.  And that is what icmp_hdr() is doing, so there is
no requirement that the compiler does anything reasonable with the
result.  Removing that cast (using skb_transport_header() instead of
icmp_hdr()) should avoid that.

(We do generally assume, however, that if the processor can handle
unaligned accesses in a useful way then the compiler will be reasonable
and not break them.)

Ben.
 

quoted

Or will this only happen on archs which __HAVE_ARCH_MEMCPY? (But looking
at a couple of arch/xxx/lib/string.c, these too seem to take alignment
into account.)

Since icmp_hdr is 64 bits you might be able to use get_unaligned64
in some way.