[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20150219.150500.834870317013347277.davem@davemloft.net>
Date: Thu, 19 Feb 2015 15:05:00 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: eyal.birger@...il.com
Cc: netdev@...r.kernel.org, edumazet@...gle.com,
shmulik.ladkani@...il.com
Subject: Re: [PATCH net-next v2 2/3] net: use skb->priority for overloading
skb->dropcount and skb->reserved_tailroom instead of skb->mark
From: Eyal Birger <eyal.birger@...il.com>
Date: Thu, 12 Feb 2015 06:32:14 +0200
> The purpose of overloading skb->priority is solely for retaining
> struct sk_buff size; skb->priority is not used after the skb queued
> to the socket and has the same guarentee of not being shared as
> skb->mark.
I don't think this analysis is accurate.
> @@ -621,7 +621,7 @@ struct sk_buff {
> __u16 csum_offset;
> };
> };
> - __u32 priority;
> + __u32 mark;
> int skb_iif;
> __u32 hash;
> __be16 vlan_proto;
> @@ -636,7 +636,7 @@ struct sk_buff {
> __u32 secmark;
> #endif
> union {
> - __u32 mark;
> + __u32 priority;
> __u32 dropcount;
> __u32 reserved_tailroom;
> };
> --
You are going to now write to dropcount in packet_rcv() and that will
corrupt skb->priority. If we got to packet_rcv() via
dev_queue_xmit_nit() then that skb->priority value is actually going
to be used by the packet schedulers for classification, flow
scheduling, etc.
So I don't think this transformation is going to work properly.
I'm also wondering if aliasing with skb->mark, which is what happens
now, is legal too.
--
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