On Sat, 2006-01-07 at 13:28 +0200, Thomas Graf wrote: > * jamal <[EMAIL PROTECTED]> 2006-06-30 22:59
> Please enlighten me, I may be making a wrong assumption again. > > 1) tc_verd is reset to 0 after dq in ri_tasklet() > 2) TC_AT is set to AT_EGRESS in dev_queue_xmit() > 3) TC_FROM being derived from TC_AT in tcf_mirred() when redirecting > 4) TC_FROM has the value AT_EGRESS when entering ifb_xmit() > Let me answer the next bit and it may clear this. > > different instances of the same device do not deadlock. If however, you > > have a series of devices in which A->B->C->D->A then you will have a > > possible deadlock. In the case of the ifb i dissallowed it because it > > was obvious from the testing. > > Correct me if I'm wrong. The skb is queued between each device. When > moving skbs from rq to tq the tx lock is acquired, if not available > the packet is requeued for later. Due to the queueing the tx lock > of the previous device is released. Where exactly is the deadlock? using what i said as looping in the case of A->B->C->D->A for the case of egress since that is what you are alluding to; note that ifb0 will be entered twice: First for example the tasklet in ifb0 will emit the packet, and then it will go all the way back to xmit on ifb0. This is where the issue is. Does that clear it? cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
