Comment 17 for bug 1349768

Revision history for this message
Tero Marttila (terom) wrote :

NACK

The same faulty behaviour persists with linux-image-3.13.0-33-generic=3.13.0-33.58~lp1349768v201407290941 (uname 3.13.0-33-generic #58~lp1349768v201407290941).

I do not notice any difference; identical symptoms. `rmmod ip_vs_rr ip_vs` continues to immediately resolve the fault.

Note that my configuration also includes openvswitch. The tftp stall continues to happen when flushing the ipvs ruleset, only unloading the ip_vs module resolves it. However, only re-loading the ip_vs_rr module does not trigger the stall, but loading the ipvs ruleset does. My IPVS ruleset consists of only four TCP "Masq" forwards.

Using ktrace to try and get a rough stack trace, I was able to observe the following sequences:

         dnsmasq-5012 [001] .... 2060.572946: ipv6_find_hdr <-ip_vs_out.part.23
         dnsmasq-5012 [001] .... 2060.572955: <stack trace>
 => ip_vs_local_reply6
 => nf_iterate
 => nf_hook_slow
 => __ip_local_out
 => ip_local_out
 => ip_send_skb
 => udp_send_skb
 => udp_sendmsg
 => inet_sendmsg
 => sock_sendmsg
 => SYSC_sendto
 => SyS_sendto
 => tracesys
         dnsmasq-5012 [001] .... 2060.572956: ipv6_find_hdr <-ip_vs_out_icmp_v6.isra.22
         dnsmasq-5012 [001] .... 2060.572963: <stack trace>
 => ip_vs_out.part.23
 => ip_vs_local_reply6
 => nf_iterate
 => nf_hook_slow
 => __ip_local_out
 => ip_local_out
 => ip_send_skb
 => udp_send_skb
 => udp_sendmsg
 => inet_sendmsg
 => sock_sendmsg
 => SYSC_sendto
 => SyS_sendto
 => tracesys

with the first sequence being repeated for every packet (?) and the second, slightly different, sequence corresponding per the timestamp to the dmesg:

[ 2060.572964] IPv6 header not found

This is with a my full iptables rulset loaded, but my OUTPUT DROP rules counters do not indicate any matches. The ftrace output seems to be identical with the iptables ruleset flushed.