netdev - Re: iproute2 / tbf with large burst seems broken again

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: <20090825062203.GA5381@ff.dom.local>
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