netdev - Re: Why do we prefer skb->priority to tc filters?

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: <CA+GmxbbGHXrZ6OrwPm0WBzk89iK94wyzJJAqbqw_XbVELvy9nQ@mail.gmail.com>
Date:	Thu, 12 Mar 2015 11:53:25 +0400
From:	Dmitry Sytchev <kbdfck@...il.com>
To:	netdev@...r.kernel.org
Subject: Re: Why do we prefer skb->priority to tc filters?

Sorry for slight offtopic, but for some reason, recent netfilter SET
changes, which allow setting queue number and priority via ipset
skbinfo extension, don't work with multiple HTB on top of multiq or
mq.
At the same time, tc filters set on outbound iface with skbedit works
fine both for prio and queue number.
How can I find the difference in their behaviour to trace where queue
number set by ipset match gets lost?

> Google definitely uses this model, as netfilter code runs on multiple
> cpus, while HTB classifier runs under qdisc spinlock, so far.
>
> If you believe root user should not set skb->priority to arbitrary
> values, this is a very different concern.

-- 
Best regards,

Dmitry Sytchev,
IT Engineer
--
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