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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4F859868.8090808@xdin.com>
Date:	Wed, 11 Apr 2012 14:39:57 +0000
From:	Arvid Brodin <Arvid.Brodin@...n.com>
To:	Stephen Hemminger <shemminger@...tta.com>
CC:	Ben Hutchings <bhutchings@...arflare.com>,
	David Miller <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"balferreira@...glemail.com" <balferreira@...glemail.com>
Subject: Re: [RFC] net/hsr: Add support for IEC 62439-3 High-availability
 Seamless Redundancy

On 2012-04-11 03:28, Stephen Hemminger wrote:
> 
>> 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?
>>
> 
> Reading Documentation/unalgined-memory-access.txt suggests that you
> probably should copy the skb before passing up the stack (if necessary).
> That is safe (but slightly slower).

Ok, so my patch does the right thing then? I.e. if no HAVE_EFFICIENT_UNALIGNED_ACCESS and
the user does not choose to pad the HSR tag (with NONSTANDARD_HSR), we memmove the payload
(look in hsr_rcv()).

Or do you want me to remove the option to pad the HSR tag to get rid of the memmove if we
don't HAVE_EFFICIENT_UNALIGNED_ACCESS?

-- 
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.--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html