Thanks. I have pushed this to my ipvs branch and will see about getting it included in 3.5. It appears that this problem has been present since (at least) 2.6.37 and my feeling is that it is -stable
Hello, For the fix below: Acked-by: Julian Anastasov <ja@xxxxxx> Simon, the change looks ok. ip_vs_ftp_init_conn is called from context where cp->lock is not locked (no double lock), so it should be
We're using sync. No. I just found 2.6.32.34 kernel differ from upstream kernel, 2.6.32 kernel doesn't have ip_vs_try_bind_dest(), but ip_vs_process_message() kernel might change conn flags without l
Hello, What we see here is 120 seconds between 2680191 and 2680311. It can mean 2 things: - some state timeout, it depends on your forwarding method. What is it? NAT? DR? - 60 seconds for ip_vs_conn_
ip_vs_bind_app() is also called by ip_vs_try_bind_dest(), which can be traced to ip_vs_proc_conn(). I've checked the changes in upstream, but nothing helps since aea9d711 has been taken into 2.6.32.2
Thanks for being thorough. Acked-by: Simon Horman <horms@xxxxxxxxxxxx> Pablo, can you handle this directly through your tree? I think it also needs to go to -stable. -- To unsubscribe from this list:
Hello, Hm, ip_vs_ftp_init_conn is called before 1st hashing, from ip_vs_bind_app() in ip_vs_conn_new() before ip_vs_conn_hash(). It should be another problem with the flags. How different is IPVS in
We met a kernel panic in 2.6.32.43 kernel: [2680191.848044] IPVS: ip_vs_conn_hash(): request for already hashed, called from run_timer_softirq+0x175/0x1d0 <snip> [2680311.849009] general protection f