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] [day] [month] [year] [list]
Message-ID: <20150616115905.GB2917@io.lakedaemon.net>
Date:	Tue, 16 Jun 2015 11:59:05 +0000
From:	Jason Cooper <jason@...edaemon.net>
To:	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
Cc:	Simon Guinot <simon.guinot@...uanux.org>,
	Andrew Lunn <andrew@...n.ch>,
	Gregory Clement <gregory.clement@...e-electrons.com>,
	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
	netdev@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	stable@...r.kernel.org
Subject: Re: [PATCH 1/2] net: mvneta: introduce tx_csum_limit property

Thomas, Simon,

On Tue, Jun 16, 2015 at 12:00:34PM +0200, Thomas Petazzoni wrote:
> On Mon, 15 Jun 2015 17:54:41 +0200, Simon Guinot wrote:
> > > The current armada-370-neta would limit the HW checksumming features to
> > > packets smaller than 1600 bytes, while a new armada-xp-neta would not
> > > have this limit.
> > 
> > This was also my first idea. But by doing this, we take the risk of
> > losing the HW checksumming feature with jumbo frames on some currently
> > working Armada XP setups. This may happen for example if a user is able
> > to update the kernel but not the on-board DTB. In order to fix a feature
> > on a SoC, we are breaking the DTB-kernel compatibility for the very same
> > feature on an another SoC. I am not sure it is OK.

Frankly, this isn't a realistic scenario.  We've said from day one that
if the dtb is provided with the board that it needs to be updateable.
For exactly these kinds of situations.  Also, Thomas' assessment is
correct, everyone we've ever spoken to is keeping the dtb in sync with
the kernel.

As long as a board with the old dtb boots a newer kernel without
crashing, then it's fine.  afaict in this situation, the updated driver
should limit HW checksumming for packets >1600 bytes if the compatible
string is 'armada-370-neta'.  Regardless of actual SoC underneath.
If the driver gets 'armada-xp-neta' then there is no checksum limit.

Users with an Armada XP SoC and an old dtb will need to upgrade the dtb
in order to make use of HW checksumming on jumbo packets with newer
kernels.  Seems sane to me.

thx,

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