netdev - Re: [PATCH v4] net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)

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: <523CF63D.7030505@xdin.com>
Date:	Sat, 21 Sep 2013 03:28:29 +0200
From:	Arvid Brodin <arvid.brodin@...n.com>
To:	David Miller <davem@...emloft.net>
CC:	Arvid Brodin <arvid.brodin@...n.com>, <netdev@...r.kernel.org>,
	<shemminger@...tta.com>, <joe@...ches.com>, <jboticario@...il.com>,
	<balferreira@...glemail.com>, <elias.molina@....es>
Subject: Re: [PATCH v4] net/hsr: Add support for the High-availability Seamless
 Redundancy protocol (HSRv0)

On 2013-09-21 03:03, Arvid Brodin wrote:
> On 2013-09-21 02:43, Arvid Brodin wrote:
>> It's weird though, the "len" bug doesn't show up in my practical tests - 
>> scp of 16 MiB file (sha1sum compared afterwards) and ping with default 
>> and 65 KB packets work just fine before and after this change - even
>> between one fixed system and one with the bug remaining. Could it be
>> that none of the network device drivers we use (e1000e and macb) make 
>> use of nonlinear skbs?
> 
> Forget about this, e1000e is running on an architecture with 
> HAVE_EFFICIENT_UNALIGNED_ACCESS, and on macb it does affect things - 
> with the "fix" nothing works. :-| 

... and that is because I have already shortened the packet through the
call to strip_hsr_tag() a few lines above, which calls 
skb_pull(..., HSR_TAGLEN) in turn. So ->len is already correct.

Moving both ->data and ->tail, and all data between them, HSR_TAGLEN bytes
lower, should not be a problem if

a) the space ahead of ->data is vacant (not part of the packet),
b) there is enough headroom,
c) it does not break 32-bit alignment, and
d) there are no references to headers etc in the data being moved.

Right? 


-- 
Arvid Brodin | Consultant (Linux)
XDIN AB | Knarrarnäsgatan 7 | SE-164 40 Kista | Sweden | 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