From: Arvid Brodin <Arvid.Brodin@xdin•com>
To: Stephen Hemminger <shemminger@vyatta•com>,
Ben Hutchings <bhutchings@solarflare•com>,
David Miller <davem@davemloft•net>
Cc: "netdev@vger•kernel.org" <netdev@vger•kernel.org>,
"balferreira@googlemail•com" <balferreira@googlemail•com>
Subject: Re: [RFC] net/hsr: Add support for IEC 62439-3 High-availability Seamless Redundancy
Date: Wed, 11 Apr 2012 00:00:13 +0000 [thread overview]
Message-ID: <4F84CA36.7020209@xdin.com> (raw)
In-Reply-To: <20120406111912.172bb1fb@nehalam.linuxnetplumber.net>
On 2012-04-06 20:19, Stephen Hemminger wrote:
> On Fri, 6 Apr 2012 18:06:31 +0100
> Ben Hutchings <bhutchings@solarflare•com> wrote:
>
>> 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.)
>>>
>>
>
> Since icmp_hdr is 64 bits you might be able to use get_unaligned64
> in some way.
>
I'm sorry, I have no idea how to do this. Besides, get_unaligned64 seems to be implemented
for the "c6x" arch only?
So far we have:
1) icmp_hdr() casts an unaligned char * to a wider type, which is bad (undefined).
2) We cannot use skb_transport_header():
On 2012-04-06 00:31, David Miller wrote:
> From: Ben Hutchings <bhutchings@solarflare•com>
> Date: Thu, 5 Apr 2012 20:21:08 +0100
>>
>> So presumably icmp_hdr() should be changed to skb_transport_header().
>
> I would not say so. Otherwise we introduce ugly casts everywhere.
>
3) My feeble suggestion to cast icmp_hdr() to (char *) is of course even worse (it doesn't
even avoid the erroneous cast in the first place).
So what do we do?
--
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 name Xdin. Read more at www.xdin.com.
next prev parent reply other threads:[~2012-04-11 0:14 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
2012-04-06 18:19 ` Stephen Hemminger
2012-04-11 0:00 ` Arvid Brodin [this message]
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=4F84CA36.7020209@xdin.com \
--to=arvid.brodin@xdin$(echo .)com \
--cc=balferreira@googlemail$(echo .)com \
--cc=bhutchings@solarflare$(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