Hmm, looks like we pushed wrong header size here. tcf_mirred_init()
checks if we could push hard header by checking the type of the target device,
while in tcf_mirred() we push the ->hard_header_len of the source device
where this skb is received. I am not sure at all.
Jamal, does the following patch make any sense for you?
---
From: Jamal Hadi Salim <jhs@mojatatu.com> Date: 2014-05-08 10:13:55
Hi Cong,
Sorry for the latency - on travel mode.
On 05/06/14 18:30, Cong Wang wrote:
On Tue, May 6, 2014 at 8:16 AM, Stephen Hemminger
[off-list ref] wrote:
Hmm, looks like we pushed wrong header size here. tcf_mirred_init()
checks if we could push hard header by checking the type of the target device,
while in tcf_mirred() we push the ->hard_header_len of the source device
where this skb is received. I am not sure at all.
Jamal, does the following patch make any sense for you?
Dont feel like that patch would help. Scratching my head....
One way to tell is to: ifconfig down the source (which seems like tunnel
device) and install all the rules then last step is ifconfig first ifb,
then the tunnel device. And if it works with current kernel patch is not
needed. It feels like some race condition between installing
rule and using it i.e rule gets installed and when still trying to
advertise to user space, a packet arrives and starts using it.
If the above works - then the question to d77190@mail.ru is what kernel
this is and when did this last work as installed?
[My gut feeling is it may have something to do with the rcu changes
perhaps - but not sure.]
cheers,
jamal
From: Cong Wang <hidden> Date: 2014-05-09 18:31:54
On Thu, May 8, 2014 at 3:13 AM, Jamal Hadi Salim [off-list ref] wrote:
Hi Cong,
Sorry for the latency - on travel mode.
On 05/06/14 18:30, Cong Wang wrote:
quoted
On Tue, May 6, 2014 at 8:16 AM, Stephen Hemminger
[off-list ref] wrote:
quoted
Hmm, looks like we pushed wrong header size here. tcf_mirred_init()
checks if we could push hard header by checking the type of the target
device,
while in tcf_mirred() we push the ->hard_header_len of the source device
where this skb is received. I am not sure at all.
Jamal, does the following patch make any sense for you?
Dont feel like that patch would help. Scratching my head....
One way to tell is to: ifconfig down the source (which seems like tunnel
device) and install all the rules then last step is ifconfig first ifb,
then the tunnel device. And if it works with current kernel patch is not
needed. It feels like some race condition between installing
rule and using it i.e rule gets installed and when still trying to
advertise to user space, a packet arrives and starts using it.
If the above works - then the question to d77190@mail.ru is what kernel
this is and when did this last work as installed?
It's an old kernel, 3.2.58. :-/
Please try to reproduce it on the latest kernel if possible.
From: Jamal Hadi Salim <jhs@mojatatu.com> Date: 2014-05-11 11:30:18
On 05/09/14 14:31, Cong Wang wrote:
It's an old kernel, 3.2.58. :-/
The email wasnt clear.
Please try to reproduce it on the latest kernel if possible.
Also - try what i said in ifconfig up interfaces last and
see if that resolves it (that would still point to some
lock/rcu changes that may have happened earlier than your
changes; i.e something is no longer protecting user space
from data path activity).
cheers,
jamal