[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20081021.164121.257737412.davem@davemloft.net>
Date: Tue, 21 Oct 2008 16:41:21 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: avillaci@...bo.fiec.espol.edu.ec
Cc: netdev@...r.kernel.org, jarkao2@...il.com, jussi.kivilinna@...et.fi
Subject: Re: Regression: Recent networking (qdisc?) patches break
irda_get_next_speed()
From: Alex Villacís Lasso <avillaci@...bo.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.
--
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