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, 10 Dec 2013 10:29:28 +0800 From: Yang Yingliang <yangyingliang@...wei.com> To: Eric Dumazet <eric.dumazet@...il.com> CC: <davem@...emloft.net>, <netdev@...r.kernel.org>, David Laight <David.Laight@...LAB.COM>, <brouer@...hat.com>, <jpirko@...hat.com>, <jbrouer@...hat.com> Subject: Re: [PATCH RFC ] net: sched: tbf: fix the calculation of max_size On 2013/12/9 23:12, Eric Dumazet wrote: > On Mon, 2013-12-09 at 21:10 +0800, Yang Yingliang wrote: >> From: Yang Yingliang <yangyingliang@...wei.com> >> >> Current max_size is caluated from rate table. Now, the rate table >> has been replaced and it's wrong to caculate max_size based on this >> rate table. It can lead wrong calculation of max_size. >> >> The burst in kernel may be lower than user asked, because burst may gets >> some loss when transform it to buffer(E.g. "burst 40kb rate 30mbit/s") >> and it seems we cannot avoid this loss. Burst's value(max_size) based on >> rate table may be equal user asked. If a packet's length is max_size, this >> packet will be stalled in tbf_dequeue() because its length is above the >> burst in kernel so that it cannot get enough tokens. The max_size guards >> against enqueuing packet sizes above q->buffer "time" in tbf_enqueue(). >> >> To make consistent with the calculation of tokens, this patch add a helper >> psched_ns_t2l() to calculate burst(max_size) directly to fix this problem. >> >> After this fix, we can support to using 64bit rates to calculate burst as well. >> >> Signed-off-by: Yang Yingliang <yangyingliang@...wei.com> >> --- >> net/sched/sch_tbf.c | 203 +++++++++++++++++++++++++++++++++++++++------------- >> 1 file changed, 155 insertions(+), 48 deletions(-) > > > There is no way I am going to study this patch. > > There is no way 32bit * 32bit multiply can overflow 64bit. > > If the user gave a stupid input, like a buffer bigger than 4 sec, just > say no. Nobody ever did such stupid things in the past, and nobody will > do in the future because it is so wrong and useless. > > q->mtu = max_t(u64, ~0U, PSCHED_TICKS2NS(qopt->mtu)); > > q->buffer = max_t(u64, ~0U, PSCHED_TICKS2NS(qopt->buffer)); > > Could we keep this code understandable, please ? Hmm, I cannot figure out why max_t, did you mean min_t? > > > > > -- 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