A bug was reported against our kernel, which looks to be an upstream issue after some testing (as of 3.17-rc1). In short, it seems that using ip_vs with something like dnsmasq-tftp to send data will cause the transfer to stop at some point where the read will error giving EPERM. It was discovered that CONFIG_IP_VS_IPV6 was the change that introduce this difference in behavor. The bug report is here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1349768 Which includes a test case in order to reproduce this issue: https://launchpadlibrarian.net/182765875/lp1349768.sh We've just recently enabled CONFIG_IP_VS_IPV6, which exposed this issue; and the user is not using IPV6 functionality. I've traced through the code and found that this segment in net/netfilter/ipvs/ip_vs_core.c function ip_vs_out is what triggers this issue, if commented out the problem does not occur: #ifdef CONFIG_IP_VS_IPV6 if (af == AF_INET6) { if (unlikely(iph.protocol == IPPROTO_ICMPV6)) { int related; int verdict = ip_vs_out_icmp_v6(skb, &related, hooknum, &iph); if (related) return verdict; } } else #endif Printk'ing further into this, I see that ip_vs_out_icmp_v6 utimately fails as frag_safe_skb_hp return NULL when packets are no longer being sent with the test case. Any suggestions for a fix for this issue, or a places to continue looking? I'd be happy to continue hacking on this and provide testing. (Resending because I sent to the incorrect ML address...) Thanks, --chris j arges -- To unsubscribe from this list: send the line "unsubscribe lvs-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
