netdev - Re: Not understand some in htb_do

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: <478CD741.7040004@trash.net>
Date:	Tue, 15 Jan 2008 16:54:41 +0100
From:	Patrick McHardy <kaber@...sh.net>
To:	Martin Devera <devik@....cz>
CC:	Badalian Vyacheslav <slavon@...telecom.ru>, netdev@...r.kernel.org
Subject: Re: Not understand some in htb_do_events function

Martin Devera wrote:
> Patrick McHardy wrote:
>> Badalian Vyacheslav wrote:
>>> Hello all.
>>> I have many messages like "htb: too many events !" in dmesg.
>>>
>>> Try to see code and find that function try do 500 events at call.
>>> Hm... may anyone ask why 500? Why its not dynamic value based on 
>>> performance of PC?
>>
>>
>> Thats a good question, I wonder why it is limited at all.
>> Martin, any hints?
>>
> Hi, I recently replied someone to the same question:
> 
>  > it is possible when during one jiffie (1 or 10ms) more than 500 classes
>  > changed its state. It is meant to protect your system from livelock.
>  > The constant should be set to something like
>  > bogomips/bogocomplexity_of_state_change but it was not done.
> 
> the solution I have in my mind is to change
>    if (net_ratelimit())
>                  printk(KERN_WARNING "htb: too many events !\n");
>          return HZ/10;
>  to
>    return 1;
> 
> to drain extra events asap. It the time of writing I was not able to
> come with better solution and there were more bugs related to this
> part of code than now.

So this was meant to protect against endless loops?

> We want way to smooth big burst of events over more dequeue invocations
> in order to not slow dequeue too much. Constant 500 is max. allowed
> "slowdown" of dequeue.
> Any bright idea how to do it more elegant, Patrick ?


Unfortunately not, but I believe simply removing the limit
completely would be better than picking an arbitary value.
--
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