netdev - Re: [PATCH v2] pkt_sched: sch_drr: Fix drr

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] [day] [month] [year] [list]

Message-ID: <492BE49C.6060408@trash.net>
Date:	Tue, 25 Nov 2008 12:42:20 +0100
From:	Patrick McHardy <kaber@...sh.net>
To:	David Miller <davem@...emloft.net>
CC:	jarkao2@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCH v2] pkt_sched: sch_drr: Fix drr_dequeue() loop

David Miller wrote:
> Things seem to have settled, thus I have applied Patrick's version
> of the fix.

Thanks.

> But I encourage people to add the necessary framework such that
> such unwanted configurations can be in fact detected at ->init()
> time and thus properly warned about.
> 
> Silent packet dropping really upsets users.

The packets won't be dropped, the qdisc will simply wait until the
throttled inner qdisc becomes active again.

Refusing incorrect changes in ->init() is not easy because at least
HFSC can switch between work-conserving and non-work-conserving
through ->change(), so the upper qdisc would have to be able to
perform validation before the change is made. This is additionally
complicated by the fact that (in case of HFSC) it can't be determined
by looking only at the class that is currently changed, the use
of a upper-limit curve on any class makes it non-work-conserving.

Perhaps its best to ignore this special case and always treat HFSC
as non-work-conserving, I haven't seen a configuration which uses
a hierarchical qdisc as inner qdisc so far.

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