linux-kernel - 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <6599ad830807220514m5afea0fcsb99bf2e95f401c36@mail.gmail.com>
Date:	Tue, 22 Jul 2008 08:14:16 -0400
From:	"Paul Menage" <menage@...gle.com>
To:	"Patrick McHardy" <kaber@...sh.net>
Cc:	"Ranjit Manomohan" <ranjitm@...gle.com>,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	lizf@...fujitsu.com
Subject: Re: [PATCH] Traffic control cgroups subsystem

On Tue, Jul 22, 2008 at 6:35 AM, Patrick McHardy <kaber@...sh.net> wrote:
>
> Does this really have to be a new skb member? You could
> simply use skb->sk->sk_cgroup_classid directly, or if
> that doesn't work, maybe skb->priority.
>

We were actually using skb->priority in our internal version of this
patch. I suggested that the separate cgroup_classid field be added
since it might be considered an abuse of skb->priority and would
interfere with existing users of that. If that's not an issue then
reusing skb->priority is certainly possible.

Regarding skb->sk->sk_cgroup_classid, is it always the case that the
original sk is still available when we're making traffic control
decisions? I'd thought that there were cases (e.g. cloning skbs in the
TCP retransmit path) where the pointer to the original sk is lost.

Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/