Re: Regression: Recent networking (qdisc?) patches break irda_get_next_speed()

[David Miller <davem@davemloft.net>]

From: Alex Villací­s Lasso <avillaci@ceibo.fiec.espol.edu.ec>
Date: Tue, 21 Oct 2008 18:37:56 -0500

> So then, the bug is that the cb field in the struct sk_buff is being
> interpreted as both a struct qdisc_skb_cb and an struct irda_skb_cb,
> for the same instance of struct sk_buff. I have just started to
> review the suggested patch, but it seems that 'struct qdisc_skb_cb'
> was meant to be aliased against the data for other layers (as
> suggested by the presence of a 'char data[]' field). If so, how come
> only IrDA is affected? How come UDP, TCP, etc. not affected by this?
> On the other hand, if qdisc_skb_cb was not meant to be aliased, then
> the IrDA case was left out while converting the rest of the layers
> so that they will skip over the member 'pkt_len' of the 'struct
> qdisc_skb_cb'.

The SKB control block is not aliased.

Once the packet is given to dev_queue_xmit() the packet scheduler
"owns" the control block of the SKB.

What IRDA is doing is illegal, and breaks in other ways without the
commit in question.

IRDA cannot depend upon the SKB control block not changing across
the dev_queue_xmit() call.