Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[RFC\s+net\-next\]\s+ipv6\:\s+Use\s+destination\s+address\s+determined\s+by\s+IPVS\s*$/: 28 ]

Total 28 documents matching your query.

1. Re: [RFC net-next] ipv6: Use destination address determined by IPVS (score: 1)
Author: Julian Anastasov <ja@xxxxxx>
Date: Sun, 20 Oct 2013 15:27:40 +0300 (EEST)
Hello, I tested with this flag, even with your patch, added printk in rt6_probe_deferred() to be sure. But in my setup without router I can not test it fully. I'm on 32-bit platform, so may be the sh
/html/lvs-devel/2013-10/msg00041.html (12,194 bytes)

2. Re: [RFC net-next] ipv6: Use destination address determined by IPVS (score: 1)
Author: Julian Anastasov <ja@xxxxxx>
Date: Sun, 20 Oct 2013 11:33:54 +0300 (EEST)
Hello, Aha, I see. Hm, no. I'll enable it. But it works for RTF_GATEWAY, something I didn't tested before now. I'll try it. But note that my test setup has no any routers around. Regards -- Julian An
/html/lvs-devel/2013-10/msg00040.html (12,357 bytes)

3. Re: [RFC net-next] ipv6: Use destination address determined by IPVS (score: 1)
Author: Hannes Frederic Sowa <hannes@xxxxxxxxxxxxxxxxxxx>
Date: Sun, 20 Oct 2013 09:33:08 +0200
The caller I found was ip6t_do_table which does deactivate bottom halves. Maybe there are others I did not see, so double checking is better. Is your kernel compiled with CONFIG_IPV6_ROUTER_PREF? Ok,
/html/lvs-devel/2013-10/msg00039.html (16,169 bytes)

4. Re: [RFC net-next] ipv6: Use destination address determined by IPVS (score: 1)
Author: Julian Anastasov <ja@xxxxxx>
Date: Sun, 20 Oct 2013 10:11:16 +0300 (EEST)
Hello, May be, I'll check it again, for now I see only rcu_read_lock() in nf_hook_slow() which is preemptable. Looking at rcu_preempt_note_context_switch, many levels of RCU locks are preemptable too
/html/lvs-devel/2013-10/msg00038.html (13,700 bytes)

5. Re: [RFC net-next] ipv6: Use destination address determined by IPVS (score: 1)
Author: Hannes Frederic Sowa <hannes@xxxxxxxxxxxxxxxxxxx>
Date: Sun, 20 Oct 2013 08:47:33 +0200
Yup, I have a patch in works wich defers the ndisc_send_ns call in rt6_probe into a workqueue out of the call stack. This should solve the problem. Still wonder if there is a nicer api as to create a
/html/lvs-devel/2013-10/msg00037.html (12,497 bytes)

6. Re: [RFC net-next] ipv6: Use destination address determined by IPVS (score: 1)
Author: Julian Anastasov <ja@xxxxxx>
Date: Sun, 20 Oct 2013 09:39:26 +0300 (EEST)
Hello, Thanks for the confirmation! I'll try later to reproduce such problem with TEE, it is interesting to know the real reason for this loop. Regards -- Julian Anastasov <ja@xxxxxx> -- To unsubscri
/html/lvs-devel/2013-10/msg00036.html (12,469 bytes)

7. Re: [RFC net-next] ipv6: Use destination address determined by IPVS (score: 1)
Author: Hannes Frederic Sowa <hannes@xxxxxxxxxxxxxxxxxxx>
Date: Sun, 20 Oct 2013 00:39:22 +0200
Ergh, this seems to break loopback then. -- 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://vg
/html/lvs-devel/2013-10/msg00035.html (11,154 bytes)

8. Re: [RFC net-next] ipv6: Use destination address determined by IPVS (score: 1)
Author: Hannes Frederic Sowa <hannes@xxxxxxxxxxxxxxxxxxx>
Date: Sun, 20 Oct 2013 00:36:57 +0200
It seems tables are processed with bh disabled, so no preemption while recursing. So I guess the use of tee_active is safe for breaking the tie here. The reason I exhaust stack space is that we can a
/html/lvs-devel/2013-10/msg00034.html (14,412 bytes)

9. Re: [RFC net-next] ipv6: Use destination address determined by IPVS (score: 1)
Author: Hannes Frederic Sowa <hannes@xxxxxxxxxxxxxxxxxxx>
Date: Sat, 19 Oct 2013 20:34:33 +0200
Oh, sorry, you are right. It happens with an unpatched net-next kernel, too. I inserted the TEE rule in mangel/OUTGOING and had only one route, ip -6 r a default via fe80::1 dev eth0 which at the tim
/html/lvs-devel/2013-10/msg00033.html (12,857 bytes)

10. Re: [RFC net-next] ipv6: Use destination address determined by IPVS (score: 1)
Author: Julian Anastasov <ja@xxxxxx>
Date: Sat, 19 Oct 2013 19:37:10 +0300 (EEST)
Hello, Problem with process stack? May be some packet loop happens? Because I can not reproduce such problem in my virtual setup, I tested TEE too, with careful packet matching and 1 CPU. Should I as
/html/lvs-devel/2013-10/msg00032.html (11,918 bytes)

11. Re: [RFC net-next] ipv6: Use destination address determined by IPVS (score: 1)
Author: Hannes Frederic Sowa <hannes@xxxxxxxxxxxxxxxxxxx>
Date: Fri, 18 Oct 2013 18:33:53 +0200
I don't think that is the reason. Just checked, I had the same panic. Greetings, Hannes -- To unsubscribe from this list: send the line "unsubscribe lvs-devel" in the body of a message to majordomo@x
/html/lvs-devel/2013-10/msg00031.html (11,513 bytes)

12. Re: [RFC net-next] ipv6: Use destination address determined by IPVS (score: 1)
Author: Julian Anastasov <ja@xxxxxx>
Date: Fri, 18 Oct 2013 09:33:13 +0300 (EEST)
Hello, May be a side effect of using some multicast address? Can you test it with such address check?: if (rt->rt6i_flags & RTF_GATEWAY || ipv6_addr_type(&rt->rt6i_gateway) & IPV6_ADDR_UNICAST) Regar
/html/lvs-devel/2013-10/msg00030.html (11,814 bytes)

13. Re: [RFC net-next] ipv6: Use destination address determined by IPVS (score: 1)
Author: Hannes Frederic Sowa <hannes@xxxxxxxxxxxxxxxxxxx>
Date: Fri, 18 Oct 2013 04:10:08 +0200
I played around with your patch and tested xt_TEE. I added a TEE rule to mangle/OUTPUT and pinged. This happend, I have not yet analyzed it: [ 101.126649] --[ cut here ]-- [ 101.128436] BUG: unable t
/html/lvs-devel/2013-10/msg00029.html (26,458 bytes)

14. Re: [RFC net-next] ipv6: Use destination address determined by IPVS (score: 1)
Author: Julian Anastasov <ja@xxxxxx>
Date: Fri, 18 Oct 2013 02:03:27 +0300 (EEST)
Hello, [PATCH net] ipv6: always prefer rt6i_gateway if present In v3.9 6fd6ce2056de2709 ("ipv6: Do not depend on rt->n in ip6_finish_output2()." changed the behaviour of ip6_finish_output2() such tha
/html/lvs-devel/2013-10/msg00028.html (12,219 bytes)

15. Re: [RFC net-next] ipv6: Use destination address determined by IPVS (score: 1)
Author: Julian Anastasov <ja@xxxxxx>
Date: Thu, 17 Oct 2013 01:50:38 +0300 (EEST)
Hello, I'm still not sure what is needed. Looking at ip6_pol_route(), I see that everything should just work: for routes without RTF_GATEWAY flag we return cloned route from rt6_alloc_cow() with vali
/html/lvs-devel/2013-10/msg00024.html (12,465 bytes)

16. Re: [RFC net-next] ipv6: Use destination address determined by IPVS (score: 1)
Author: Hannes Frederic Sowa <hannes@xxxxxxxxxxxxxxxxxxx>
Date: Wed, 16 Oct 2013 23:59:53 +0200
To have ip6_dst_check working, there must to be a valid link from the rt6_info to the fib6_node. Otherwise we cannot check the serial number. As I currently see we also need a link from the fib6_node
/html/lvs-devel/2013-10/msg00023.html (14,748 bytes)

17. Re: [RFC net-next] ipv6: Use destination address determined by IPVS (score: 1)
Author: Julian Anastasov <ja@xxxxxx>
Date: Wed, 16 Oct 2013 23:22:40 +0300 (EEST)
Hello, In IPv4 rt->rt_flags has no bit to indicate if the route is via gateway (like RTF_GATEWAY in IPv6). We added rt_uses_gateway for this purpose. In the default case, rt_gateway may contain 0 if
/html/lvs-devel/2013-10/msg00022.html (12,514 bytes)

18. Re: [RFC net-next] ipv6: Use destination address determined by IPVS (score: 1)
Author: Hannes Frederic Sowa <hannes@xxxxxxxxxxxxxxxxxxx>
Date: Wed, 16 Oct 2013 16:32:46 +0200
I thought about this yesterday but did not see an easy way. How does the IPv4 implementation accomplish this? ipvs caches the dst in its own infrastructure, so we need to be sure we don't disconnect
/html/lvs-devel/2013-10/msg00020.html (11,929 bytes)

19. Re: [RFC net-next] ipv6: Use destination address determined by IPVS (score: 1)
Author: Julian Anastasov <ja@xxxxxx>
Date: Wed, 16 Oct 2013 10:27:47 +0300 (EEST)
Hello, Similar change in IPv4 opened the Pandora box: IPVS, xt_TEE, raw.c (IP_HDRINCL). May be the corrsponding places in IPv6 have the same problem. I don't know the IPv6 routing but if we find a wa
/html/lvs-devel/2013-10/msg00018.html (10,769 bytes)

20. Re: [RFC net-next] ipv6: Use destination address determined by IPVS (score: 1)
Author: Simon Horman <horms@xxxxxxxxxxxx>
Date: Wed, 16 Oct 2013 13:26:15 +0900
Thanks for your guidance, that possibility had occured to me too. I'll rework the patch accordingly. -- To unsubscribe from this list: send the line "unsubscribe lvs-devel" in the body of a message t
/html/lvs-devel/2013-10/msg00017.html (11,687 bytes)


This search system is powered by Namazu