Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[RFC\s+PATCH\s+net\-next\]\s+ipvs\:\s+add\s+missing\s+lock\s+in\s+ip_vs_ftp_init_conn\(\)\s*$/: 8 ]

Total 8 documents matching your query.

1. Re: [RFC PATCH net-next] ipvs: add missing lock in ip_vs_ftp_init_conn() (score: 1)
Author: Simon Horman <horms@xxxxxxxxxxxx>
Date: Tue, 10 Jul 2012 18:05:50 +0900
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
/html/lvs-devel/2012-07/msg00008.html (14,520 bytes)

2. Re: [RFC PATCH net-next] ipvs: add missing lock in ip_vs_ftp_init_conn() (score: 1)
Author: Julian Anastasov <ja@xxxxxx>
Date: Tue, 3 Jul 2012 10:12:41 +0300 (EEST)
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
/html/lvs-devel/2012-07/msg00001.html (14,045 bytes)

3. Re: [RFC PATCH net-next] ipvs: add missing lock in ip_vs_ftp_init_conn() (score: 1)
Author: Xiaotian Feng <xtfeng@xxxxxxxxx>
Date: Mon, 2 Jul 2012 18:30:08 +0800
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
/html/lvs-devel/2012-07/msg00000.html (13,322 bytes)

4. Re: [RFC PATCH net-next] ipvs: add missing lock in ip_vs_ftp_init_conn() (score: 1)
Author: Julian Anastasov <ja@xxxxxx>
Date: Fri, 29 Jun 2012 12:04:55 +0300 (EEST)
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_
/html/lvs-devel/2012-06/msg00004.html (12,389 bytes)

5. Re: [RFC PATCH net-next] ipvs: add missing lock in ip_vs_ftp_init_conn() (score: 1)
Author: Xiaotian Feng <xtfeng@xxxxxxxxx>
Date: Fri, 29 Jun 2012 09:50:59 +0800
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
/html/lvs-devel/2012-06/msg00003.html (16,101 bytes)

6. Re: [RFC PATCH net-next] ipvs: add missing lock in ip_vs_ftp_init_conn() (score: 1)
Author: Simon Horman <horms@xxxxxxxxxxxx>
Date: Fri, 29 Jun 2012 09:34:45 +0900
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:
/html/lvs-devel/2012-06/msg00002.html (13,928 bytes)

7. Re: [RFC PATCH net-next] ipvs: add missing lock in ip_vs_ftp_init_conn() (score: 1)
Author: Julian Anastasov <ja@xxxxxx>
Date: Fri, 29 Jun 2012 03:17:33 +0300 (EEST)
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
/html/lvs-devel/2012-06/msg00001.html (14,870 bytes)

8. [RFC PATCH net-next] ipvs: add missing lock in ip_vs_ftp_init_conn() (score: 1)
Author: Xiaotian Feng <xtfeng@xxxxxxxxx>
Date: Thu, 28 Jun 2012 21:36:27 +0800
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
/html/lvs-devel/2012-06/msg00000.html (12,005 bytes)


This search system is powered by Namazu