netdev - Re: [PATCH] Traffic control cgroups subsystem

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]

Date:	Thu, 24 Jul 2008 02:17:53 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Ranjit Manomohan <ranjitm@...gle.com>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	lizf@...fujitsu.com, menage@...gle.com
Subject: Re: [PATCH] Traffic control cgroups subsystem

Ranjit Manomohan wrote:
> On Wed, Jul 23, 2008 at 3:34 PM, Patrick McHardy <kaber@...sh.net> wrote:
>>
>> It is by the flow_change() function, but special casing the
>> CGROUP_CLASSID is not acceptable anyway. There should be no
>> need for that, a simple linear mapping to classids is done
>> by default in mapping mode, the sk_cgroup_classid simply
>> shouldn't include qdisc IDs.
> 
> I did not want to special case it but I want an identity mapping not a
> linear one.  For some reason a baseclass of X:0 is not allowed

An ID of X:0 identifies a qdisc, not a class, which is why this
isn't accepted.

> and
> there does not seem to be a clean way to get a 1-1 mapping (tc.classid
> -> X:tc.classid). I would have to workaround it by using a baseclass
> of the form X:Y and then subtracting Y from the value written to
> tc.classid which seemed very non intuitive.
> 
> Any particular reason for this restriction? Am I missing any other
> technique of getting a 1-1 mapping using the flow classifier?

My suggestion to replace your classifier by cls_flow was wrong, sorry.

You can't do classification that don't use linear mappings or hash
distribution, but we really should support that. We should keep your
classifier (with the change to use skb->sk), but please extend it by
the standard classifier features like ematches, actions and policers
(see flow_classify() for a simple example). Adding the cgroup to
cls_flow still makes sense, but as regular key without the baseclass
modification.
--
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