netdev - Re: [PATCH 0/6] Add qdisc->ops->peek() support.

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20081017204543.GB2527@ami.dom.local>
Date:	Fri, 17 Oct 2008 22:45:43 +0200
From:	Jarek Poplawski <jarkao2@...il.com>
To:	Patrick McHardy <kaber@...sh.net>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	Herbert Xu <herbert@...dor.apana.org.au>
Subject: Re: [PATCH 0/6] Add qdisc->ops->peek() support.

On Fri, Oct 17, 2008 at 04:12:03PM +0200, Patrick McHardy wrote:
...
> Some general thoughts ...
>
> We've never had any systematic checks for useful and non-useful
> combination of qdiscs, which is causing a lot of these complications.
> Think of all the multiq work that was required to make it work
> properly with non-work-conserving qdiscs - while at the same time,
> using a non-work-conserving qdisc (which require a global view)
> defeats basically all of the benefits.
>
> So it would be really useful to come up with a systematic definition
> of valid combinations instead of trying handling lots of purely
> theoretical case that don't make sense. One more example - all the
> qdiscs implement ->drop(), yet its only needed by CBQ and it doesn't
> make any sense at all to use lets say HFSC as child of CBQ.
>
> About this specific case - yes, it would break compatibility for
> users using f.i. TBF as child of netem. But if you look at the
> netem_enqueue() function, it in fact assumes that the inner qdisc
> is a tfifo, so we'd be breaking an already broken case. We can
> of course be nice and warn about it for a few releases, but I believe
> there is some real potential for simplification that makes it
> worth it.

I'm not sure this is all right: at least until there is not too much
problems with some code (like with requeuing). We probably should try
before this official ways like feature-removal-schedule.txt, and/or
maybe some CONFIG_XXX_DEPRECATED things. But I don't persist with this.

BTW, I'm not sure if I'm expected to redo any patches in this thread.
(Probably some things like this teql_peek() could be removed with
->requeue() killing.)

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