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
| ||
|
Date: Tue, 25 Aug 2009 06:22:03 +0000 From: Jarek Poplawski <jarkao2@...il.com> To: Denys Fedoryschenko <denys@...p.net.lb> Cc: netdev@...r.kernel.org Subject: Re: iproute2 / tbf with large burst seems broken again On 25-08-2009 01:37, Denys Fedoryschenko wrote: > Found issue, it seems tc_core_time2tick will overflow with increased > resolution on large bucket values. But no idea how to fix it :-( > > I add a warning, something like > unsigned tc_core_time2tick(unsigned time) > { > + long long temp = time*tick_in_usec; > + if (temp > INT_MAX) > + printf("tc_core_time2tick() overflow!\n"); > return time*tick_in_usec; > } > > Maybe it is good to add in iproute2 mainstream, so user will be warned if > buffer set too large? (and it will not set incorrect values, that lead to > unpredictable results. Right, it's about an overflow and it was expected (theoretically) for very low rates (as for current times) while doing this resolution change. Probably this kind of warning should be useful if we expect there're more people who can actually use something like this yet ;-) Alas INT_MAX could still be not enough to prevent similar issues because in tbf_dequeue such a value (buffer) is increased with tokens. I guess we could try to change some variables to 64 bits there, but the main question is why anybody needs such strange settings today? Did you try e.g. to browse Internet with that rate and the buffer e.g. 1500kb or you punish some users only? ;-) Btw, why do you think 'buffer 2000kb' is better "for you" with that rate than e.g. 20kb? Thanks, Jarek P. -- 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