* jamal <[EMAIL PROTECTED]> 2006-06-30 22:59 > On Sat, 2006-01-07 at 01:45 +0200, Thomas Graf wrote: > > Fact is that the from verdict is set to a meaningful value again at > > dev_queue_xmit() or ing_filter() so ifb_xmit() only sees valid values. > > Ok, Thomas this is one of those places where we end up colliding for no > good reason - your statement above is accusatory. And sometimes i say 3 > things and you pick one and use that as context. The ifb does clear the > field. So if you get redirected again, it will be 0.
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() > 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? - 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