From: Arvid Brodin <arvid.brodin@enea•com>
To: David Miller <davem@davemloft•net>
Cc: <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 19:08:03 +0200 [thread overview]
Message-ID: <4F7F22F3.7060402@enea.com> (raw)
In-Reply-To: <20120406.124344.564538802640968013.davem@davemloft.net>
David Miller wrote:
> From: Arvid Brodin <arvid.brodin@enea•com>
> Date: Fri, 6 Apr 2012 17:51:24 +0200
>
>> 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?
>
> It's not doing it with "char *", it's doing it with other types like
> the type of the ICMP header in this case.
>
> memcpy is expanded by the compiler internally into __builtin_memcpy()
> which if it sees the length is reasonably short will inline the
> copy. And subsequently it uses the alignment of the types involved
> to determine what kinds of loads and stores it can use in that
> inline memcpy().
>
> So the result is that just because in your case with your compiler
> it doesn't get expanded inline and fault, it doesn't mean it won't
> for someone else.
>
> You're just lucky, and you really haven't fixed the bug.
>
Ok. And thanks for the explanation. Would something like this do the
trick then?
+ /* Need to cast to (char *) below to keep gcc optimizations
+ from causing alignment faults. */
+ memcpy(&icmp_param.data.icmph, (char *) icmp_hdr(skb),
+ sizeof(icmp_param.data.icmph));
If not, any suggestions on how to tackle this?
--
Arvid Brodin
Enea Services Stockholm AB - since February 16 a part of Xdin in the Alten
Group. Soon we will be working under the common brand Xdin. Read more at
www.xdin.com.
next prev parent reply other threads:[~2012-04-06 17:08 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 [this message]
2012-04-06 17:06 ` Ben Hutchings
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=4F7F22F3.7060402@enea.com \
--to=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