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]
Date:	Thu, 11 Oct 2012 14:59:12 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	mbizon@...ebox.fr
Cc:	Måns Rullgård <mans@...sr.com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	netdev@...r.kernel.org, David Laight <David.Laight@...LAB.COM>,
	Jon Masters <jonathan@...masters.org>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: alignment faults in 3.6

On Thu, 2012-10-11 at 14:51 +0200, Maxime Bizon wrote:

> Hey I cannot go back in time, when that hardware was built in 2004 (mips
> @250Mhz), it was considered good, and we did manufacture a lot of it, so
> it's still maintained.
> 
> People run recent kernels on older hardware because they are *encouraged
> to do so*.
> 
> I fought inside my company to be good kernel citizen, not using
> proprietary BSP, rewrite & mainline the drivers, because that was the
> community promise: mainline it, we will support it for you, you will get
> the latest kernel features for free.
> 
> 
> That worked, but with some drawbacks:
> 
>  - kernel footprint grew that much (we started from 2.4) that it does
> not fit in device flash anymore
> 
>  - performance took a hit each time we upgrade, mostly because of cache
> footprint growth.
> 
>  - as kernel footprint grew, available RAM for conntrack & route cache
> entries was smaller each time
> 
> 
> But I had to stop upgrading after 2.6.20. Everything below is not
> anybody's fault. Bloat is unavoidable for software project that big.
> 
> I'm perfectly ok with that, but I don't want to be ridiculed for running
> mainline kernel on old hardware.

Hmm, I am sorry if you felt that, it was not my intent.

> 
> 
> > Adding get_unaligned() everywhere in linux network stacks is not an
> > option.
> > 
> > We actually want to be able to read the code and fix the bugs, not only
> > run it on a cheap low end router.
> 
> That was not a request, I just needed a clarification. 
> 
> Documentation/unaligned-memory-access.txt does not say it's a big no-no,
> it says you can give unaligned pointers to the networking stack if you
> arch can do unaligned access (with an "efficiency" notion).
> 
> MIPS and ARM have a software handler for this, and performance wise in
> my case it's better to take the faults, a driver writer may think a
> benchmark will dictate what to do.
> 

Sure, but all this discussion started because one arch apparently did
not like these mis alignments, and some people complained that network
guys would not add _needed_ get_unaligned_xxx() wrappers ...

So far, linux is 20 years old, I dont think we are going to add wrappers
right now. Machines that could have cared are dying anyway.

Please note we still support NET_IP_ALIGN, even if its 0 on x86.



--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ