netdev - Re: [RFC PATCH 1/1] IPVS netns shutdown/startup dead-lock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.1106132309440.1627@ja.ssi.bg>
Date:	Tue, 14 Jun 2011 00:25:31 +0300 (EEST)
From:	Julian Anastasov <ja@....bg>
To:	Hans Schillstrom <hans.schillstrom@...csson.com>
cc:	horms@...ge.net.au, wensong@...ux-vs.org,
	lvs-devel@...r.kernel.org, netdev@...r.kernel.org,
	netfilter-devel@...r.kernel.org, hans@...illstrom.com
Subject: Re: [RFC PATCH 1/1] IPVS netns shutdown/startup dead-lock


	Hello,

On Mon, 13 Jun 2011, Hans Schillstrom wrote:

> ip_vs_mutext is used by both netns shutdown code and startup
> and both implicit uses sk_lock-AF_INET mutex.
> 
> cleanup CPU-1         startup CPU-2
> ip_vs_dst_event()     ip_vs_genl_set_cmd()
>  sk_lock-AF_INET     __ip_vs_mutex
>                      sk_lock-AF_INET
> __ip_vs_mutex
> * DEAD LOCK *

	So, sk_lock-AF_INET is locked before calling
ip_vs_dst_event ? Do you have a backtrace for this case?
I assume your patch is tested to fix the problem ?

> This can be solved by have the ip_vs_mutex per netns
> or avid locking when starting/stoping sync-threads.
> i.e. just add a starting/stoping flag.

	sk_release_kernel is called in thread
context, so ip_vs_mutex is not involved there. We
have a problem only with start_sync_thread, right?

> ip_vs_mutex per name-space seems to be a more future proof solution.

	Global mutex protects some global lists such as
virtual services. If your patch works, better way to fix this problem
is to use some new mutex. May be we can move the IPVS_CMD_NEW_DAEMON,
IPVS_CMD_DEL_DAEMON and IP_VS_SO_GET_DAEMON code before the
__ip_vs_mutex locking. This mutex should be used for start_sync_thread,
stop_sync_thread, ip_vs_genl_dump_daemons and IP_VS_SO_GET_DAEMON.
For example, ip_vs_sync_mutex.

	Note that __ip_vs_sync_cleanup is missing a
__ip_vs_mutex lock. We have to use the new mutex there.

> Which one should be used ?

	For now __ip_vs_mutex should be global ...

Regards

--
Julian Anastasov <ja@....bg>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html