ip_vs: bug in ip_vs_out when CONFIG_IP_VS_IPV6 is enabled

To: lvs-devel@xxxxxxxxxxxxxxx
Subject: ip_vs: bug in ip_vs_out when CONFIG_IP_VS_IPV6 is enabled
Cc: Jesper Dangaard Brouer <brouer@xxxxxxxxxx>, Julian Anastasov <ja@xxxxxx>
From: Chris J Arges <chris.j.arges@xxxxxxxxxxxxx>
Date: Thu, 21 Aug 2014 14:44:36 -0500
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:

Which includes a test case in order to reproduce this issue:

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
function ip_vs_out is what triggers this issue, if commented out the
problem does not occur:

        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

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...)

--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

<Prev in Thread] Current Thread [Next in Thread>