From: Daniel Lezcano <dlezcano-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
To: "Denis V. Lunev" <den-3ImXcnM4P+0@public.gmane.org>
Cc: Linux Containers
<containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org>,
"Denis V. Lunev" <den-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>,
Benjamin Thery <benjamin.thery-6ktuUTfB/bM@public.gmane.org>,
"Eric W. Biederman"
<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>,
Pavel Emelianov <xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
Subject: Re: cleanup in workq and dst_destroy
Date: Mon, 19 Nov 2007 09:46:28 +0100 [thread overview]
Message-ID: <47414D64.9040304@fr.ibm.com> (raw)
In-Reply-To: <473DCE16.8020809-3ImXcnM4P+0@public.gmane.org>
Denis V. Lunev wrote:
> Daniel Lezcano wrote:
>> Hi all,
>>
>> while doing ipv6 namespace, we were faced to a problem with the loopback
>> and the dst_destroy function.
>>
>> When the network namespace exits, the cleanup function is called by
>> schedule_work and this function will browse the net ops list to call the
>> different exit methods for the registered subsystems.
>>
>> The different subsystems will shutdown their resources and in particular
>> addrconf subsystem will ifdown the loopback. This function will call
>> rt6_ifdown
>> -> fib6_clean_all
>> -> fib6_clean_node
>> -> fib6_clean_tree
>> -> fib6_clean_node
>> -> fib6_del
>> -> fib6_del_route
>> -> rt6_release
>> ->dst_free
>> -> __dst_free
>>
>> The __dst_free function will schedule_delayed_work the dst_gc_work
>> function.
>>
>> The dst_gc_work will call dst_destroy and finally this one will call
>> dst->ops->destroy ops function which is ip6_dst_destroy.
>>
>> The problem here is we have the workq blocked because we are running
>> inside the netns cleanup function. So the delayed work will not run
>> until we exits the cleanup function. But the loopback is still
>> referenced by the ip6 routes, the netdev_unregister will loop
>> indefinitly => dead lock.
>>
>> By the way, this bug appears with ipv6 but it is perhaps pending with ipv4.
>>
>> Benjamin as proposed to create a separate workq for the network
>> namespace, so in the worst case we have the unregister looping until the
>> ip6 route are shut downed. Is it an acceptable solution ?
>>
>
> we are doing this staff in the special thread. There are a lot of
> difficult things to perform like synchronize_net & netdev_run_todo inside
The special thread ? do you mean keventd_wq ?
next prev parent reply other threads:[~2007-11-19 8:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-16 16:32 cleanup in workq and dst_destroy Daniel Lezcano
[not found] ` <473DC604.9070601-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
2007-11-16 17:06 ` Denis V. Lunev
[not found] ` <473DCE16.8020809-3ImXcnM4P+0@public.gmane.org>
2007-11-19 8:46 ` Daniel Lezcano [this message]
[not found] ` <47414D64.9040304-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
2007-11-19 8:58 ` Denis V. Lunev
[not found] ` <4741501C.1090002-3ImXcnM4P+0@public.gmane.org>
2007-11-19 9:03 ` Daniel Lezcano
2007-11-19 9:16 ` Benjamin Thery
[not found] ` <4741546D.6010500-6ktuUTfB/bM@public.gmane.org>
2007-11-19 9:29 ` Denis V. Lunev
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=47414D64.9040304@fr.ibm.com \
--to=dlezcano-nmtc/0zbporqt0dzr+alfa@public.gmane.org \
--cc=benjamin.thery-6ktuUTfB/bM@public.gmane.org \
--cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
--cc=den-3ImXcnM4P+0@public.gmane.org \
--cc=den-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org \
--cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org \
--cc=xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox