[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHA+R7N88DFPpfPeN5cqru7oODfew1ZUdT80R0fj1QkQsx-siw@mail.gmail.com>
Date: Wed, 11 Mar 2015 15:12:19 -0700
From: Cong Wang <cwang@...pensource.com>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: netdev <netdev@...r.kernel.org>,
Jamal Hadi Salim <jhs@...atatu.com>,
David Miller <davem@...emloft.net>
Subject: Re: Why do we prefer skb->priority to tc filters?
On Wed, Mar 11, 2015 at 2:47 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> On Wed, 2015-03-11 at 13:46 -0700, Cong Wang wrote:
>
>> That is just a permission check when val > 6, given the fact most
>> daemons have root permission, I doubt your argument makes a difference
>> for discussion. At least with userns having root permission is more common.
>
> Some setups use ip[6]tables rules to mangle skb->priority to select a
> HTB class.
>
> Google definitely uses this model, as netfilter code runs on multiple
> cpus, while HTB classifier runs under qdisc spinlock, so far.
I knew we can modify skb->priority in a few ways, for example skbedit.
That is not my concern, all what I am thinking is there is some
way in application layer to bypass our tc filters, which is not expected
to happen for me. Given our specific case, I want to propose to clear
skb->priority after moving out of a netns:
diff --git a/net/core/dev.c b/net/core/dev.c
index 962ee9d..2301f01 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1694,6 +1694,7 @@ int __dev_forward_skb(struct net_device *dev,
struct sk_buff *skb)
}
skb_scrub_packet(skb, true);
+ skb->priority = 0;
skb->protocol = eth_type_trans(skb, dev);
skb_postpull_rcsum(skb, eth_hdr(skb), ETH_HLEN);
--
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
Powered by blists - more mailing lists