From: Hans Schillstrom <hans@schillstrom.com>
To: Julian Anastasov <ja@ssi.bg>
Cc: Simon Horman <horms@verge.net.au>,
netdev@vger.kernel.org, lvs-devel@vger.kernel.org,
"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: unregister_netdevice: waiting for lo to become free. Usage count = 8
Date: Mon, 18 Apr 2011 23:48:04 +0200 [thread overview]
Message-ID: <201104182348.05228.hans@schillstrom.com> (raw)
In-Reply-To: <alpine.LFD.2.00.1104182316060.1481@ja.ssi.bg>
On Monday, April 18, 2011 23:12:27 Julian Anastasov wrote:
>
> Hello,
>
> On Mon, 18 Apr 2011, Hans Schillstrom wrote:
>
> > Actually I forgot to tell there is a need for a
> > ip_vs_service_cleanup() due to above.
> > Do you see any drawbacks with it ?
>
> May be ip_vs_service_cleanup() should call only
> ip_vs_flush(), under __ip_vs_mutex.
Hmm,
I'm not sure if the IP_VS_WAIT_WHILE() in ip_vs_flush is a good idea in this case...
That was why I wrote ip_vs_service_cleanup()
>
> > /*
> > * Delete service by {netns} in the service table.
> > */
> > static void ip_vs_service_cleanup(struct net *net)
> > {
> > unsigned hash;
> > struct ip_vs_service *svc, *tmp;
> >
> > EnterFunction(2);
> > /* Check for "full" addressed entries */
> > for (hash = 0; hash<IP_VS_SVC_TAB_SIZE; hash++) {
> > write_lock_bh(&__ip_vs_svc_lock);
> > list_for_each_entry_safe(svc, tmp, &ip_vs_svc_table[hash],
> > s_list) {
> > if (net_eq(svc->net, net)) {
> > ip_vs_svc_unhash(svc);
> > __ip_vs_del_service(svc);
> > }
> > }
> > list_for_each_entry_safe(svc, tmp, &ip_vs_svc_fwm_table[hash],
> > f_list) {
> > if (net_eq(svc->net, net)) {
> > ip_vs_svc_unhash(svc);
> > __ip_vs_del_service(svc);
> > }
> > }
> > write_unlock_bh(&__ip_vs_svc_lock);
> > }
> > LeaveFunction(2);
> > }
> >
> > Called just after the __ip_vs_control_cleanup_sysctl()
>
> Hm, no. ip_vs_service_cleanup() should be called
> by ip_vs_cleanup() before or after nf_unregister_hooks().
> The rule is that ip_vs_flush() should be called before
> ip_vs_conn_flush() because after ip_vs_flush() no more
> connections can be created and even if hooks are still
> registered the packets can not create conns in the netns. Then
> ip_vs_conn_flush() will remove all existing connections and
> ip_vs_control_cleanup() can remove all real servers with
> ip_vs_trash_cleanup(). I mean, per-netns calls.
>
OK I will try to do that, both with and without throttle in ip_vs_in()
> Also, may be all code that was called in old
> kernels by ip_vs_cleanup() should be now called by
> __ip_vs_cleanup(net), i.e. we can preserve the needed order
> of all functions but now also per-netns. For example, for
> ip_vs_ctl.c ip_vs_control_init() can remain as global but it
> should not register ipvs_control_ops. Then we
> can rename __ip_vs_control_init to ip_vs_control_init_net()
> and to call it from __ip_vs_init(). I.e. all such files
> will have global function and also _init_net and
> _cleanup_net. Now there are many register_pernet_subsys()
> calls and I'm not sure we preserve the needed order for
> cleanup. Are the ->exit methods called in reverse order?
Yes
> I don't see it in ops_exit_list() and we can not rely
> on such registration order. I think, ip_vs_init() should
> call global functions as now but __ip_vs_init() and
> __ip_vs_cleanup() should call the _net methods in right
> order.
Exactly,
I have already done that in my next patch, and some other small changes :-)
For the ip_vs.ko there is only one register/unregister now, the schedulers still have their own.
Hopefully the patch is ready to morrow
Regards
Hans
next prev parent reply other threads:[~2011-04-18 21:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-15 7:01 unregister_netdevice: waiting for lo to become free. Usage count = 8 Hans Schillstrom
2011-04-15 7:27 ` Eric W. Biederman
2011-04-15 20:11 ` Julian Anastasov
2011-04-18 6:10 ` Hans Schillstrom
2011-04-18 10:43 ` Hans Schillstrom
2011-04-18 21:12 ` Julian Anastasov
2011-04-18 21:48 ` Hans Schillstrom [this message]
2011-04-18 22:23 ` Julian Anastasov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201104182348.05228.hans@schillstrom.com \
--to=hans@schillstrom.com \
--cc=ebiederm@xmission.com \
--cc=horms@verge.net.au \
--cc=ja@ssi.bg \
--cc=lvs-devel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.