netdev - Re: [PATCH] Rate should be u64 to avoid integer overflow at high speeds (>= ~35Gbit)

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: <1363155195.13690.48.camel@edumazet-glaptop>
Date:	Wed, 13 Mar 2013 07:13:15 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Bill Fink <billfink@...dspring.com>
Cc:	Thomas Graf <tgraf@...g.ch>,
	Chris Friesen <chris.friesen@...band.com>,
	Vimal <j.vimal@...il.com>, netdev@...r.kernel.org,
	shemminger <shemminger@...tta.com>
Subject: Re: [PATCH] Rate should be u64 to avoid integer overflow at high
 speeds (>= ~35Gbit)

On Wed, 2013-03-13 at 02:01 -0400, Bill Fink wrote:

> The last time this was discussed appears to be (on 2011-03-28):
> 
> 	http://marc.info/?l=linux-netdev&m=130128741907282&w=2
> 
> where Maciej Żenczykowski argued that creating a new 64-bit
> Netlink attribute for this would be much more complex than for
> the IFLA_STATS64 support.  There was no reply.
> 
> Providing a new multiplier/shift parameter would be a simple
> way to extend support for higher rates, and would not break
> existing user space that doesn't require the higher rates.
> I imagine the user would not explicitly specify the multiplier/
> shift parameter, but would just normally specify the desired
> rate, and a newer tc would figure out what multiplier/shift
> to use if a high enough rate demanded it.  To maintain user
> space compatibility, the kernel should report back the same
> rate and multiplier/shift it was given, and the newer tc would
> convert it back to the user's originally specified rate.  Older
> user space that was fine with the ~34 Gbps rate limitation would
> always have the default multiplier of 1 or shift of 0 bits, and
> would see the exact same unmultiplied/unshifted rate it always
> did.


We already said no to such a hack. Maybe its not clear enough ?

netlink allows us to a proper way, and Thomas Graf explained how we
expect the thing to be done.

Yes, this is not a one liner patch, its a bit more of work, and its how
it will be done when someone does the job.


> I also believe 32 bits of precision is significant enough
> at these higher data rates.
> 

This has nothing to do with the issue. Thats an implementation detail in
the kernel. And frankly with 64bit arches we better use 64bit native
fields, instead of adding arbitrary limits.

We are speaking of the netlink message itself and old binaries.



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