From: Ben Hutchings <bhutchings@solarflare•com>
To: Arvid Brodin <arvid.brodin@enea•com>
Cc: David Miller <davem@davemloft•net>, <shemminger@vyatta•com>,
<netdev@vger•kernel.org>, <balferreira@googlemail•com>,
<arvid.brodin@xdin•com>
Subject: Re: [RFC] net/hsr: Add support for IEC 62439-3 High-availability Seamless Redundancy
Date: Fri, 6 Apr 2012 18:06:31 +0100 [thread overview]
Message-ID: <1333731991.3282.17.camel@deadeye> (raw)
In-Reply-To: <4F7F10FC.3020308@enea.com>
On Fri, 2012-04-06 at 17:51 +0200, Arvid Brodin wrote:
> David Miller wrote:
> > From: Stephen Hemminger <shemminger@vyatta•com>
> > Date: Wed, 4 Apr 2012 16:55:59 -0700
> >
> >> 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.
> 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.)
>
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
next prev parent reply other threads:[~2012-04-06 17:06 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-27 13:20 [RFC] net/hsr: Add support for IEC 62439-3 High-availability Seamless Redundancy Arvid Brodin
2012-04-03 18:37 ` Stephen Hemminger
2012-04-04 23:09 ` Arvid Brodin
2012-04-04 23:55 ` Stephen Hemminger
2012-04-05 0:21 ` David Miller
2012-04-06 15:51 ` Arvid Brodin
2012-04-06 16:43 ` David Miller
2012-04-06 17:08 ` Arvid Brodin
2012-04-06 17:06 ` Ben Hutchings [this message]
2012-04-06 18:19 ` Stephen Hemminger
2012-04-11 0:00 ` Arvid Brodin
2012-04-11 1:28 ` Stephen Hemminger
2012-04-11 14:39 ` Arvid Brodin
2012-04-05 0:17 ` David Miller
2012-04-05 19:21 ` Ben Hutchings
2012-04-05 22:31 ` David Miller
2012-05-14 18:11 ` Arvid Brodin
2012-05-14 18:28 ` Stephen Hemminger
2012-05-24 17:09 ` Arvid Brodin
2012-05-24 17:16 ` Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1333731991.3282.17.camel@deadeye \
--to=bhutchings@solarflare$(echo .)com \
--cc=arvid.brodin@enea$(echo .)com \
--cc=arvid.brodin@xdin$(echo .)com \
--cc=balferreira@googlemail$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=netdev@vger$(echo .)kernel.org \
--cc=shemminger@vyatta$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox