Re: [PATCH 2/3] [VLAN]: Update iif when receiving via VLAN device

[Thomas Graf <tgraf@suug.ch>]

* jamal <hadi@cyberus.ca> 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?