Netdev List
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: netdev@vger.kernel.org
Cc: "bugme-daemon@kernel-bugs.osdl.org"
	<bugme-daemon@bugzilla.kernel.org>,
	kernelbmw@lsmod.de
Subject: Re: [Bugme-new] [Bug 6698] New: unregister_netdevice hangs indefinitely from /proc/sys/net/ipv6/conf/all/forwarding
Date: Mon, 19 Jun 2006 16:06:20 -0700	[thread overview]
Message-ID: <20060619160620.093eac25.akpm@osdl.org> (raw)
In-Reply-To: <200606161620.k5GGKagU011416@fire-2.osdl.org>

bugme-daemon@bugzilla.kernel.org wrote:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=6698
> 
>            Summary: unregister_netdevice hangs indefinitely from
>                     /proc/sys/net/ipv6/conf/all/forwarding
>     Kernel Version: 2.6.17-rc6
>             Status: NEW
>           Severity: normal
>              Owner: yoshfuji@linux-ipv6.org
>          Submitter: kernelbmw@lsmod.de
> 
> 
> Most recent kernel where this bug did not occur: none known (yet)
> Distribution: reproduced on Debian/stable, SuSE/10.0, SuSE/10.1
> Hardware Environment: reproduced on UML, i386, x86/64
> Software Environment: reproduced with openvpn and UML tap devices
> Problem Description: after adding IPv6 to my previously working openvpn
> tunneling setup, a (really old) IPv6-related bug started to occurr:
> http://lkml.org/lkml/2003/8/21/1
> I also reproduced this bug with kernel 2.6.15.1(vanilla,uml) and
> 2.6.16.13(SuSE-version,x86/64) and linux-2.6.13 (SuSE-version,i386)
> 
> Steps to reproduce:
> echo 0 > /proc/sys/net/ipv6/conf/all/forwarding # this is important initialization
> 
> Have (any version of) openvpn open a tunnel using a tap (virtual ethernet)
> device. In the "up" script do:
> echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
> this can be easily tested with these lines:
> apt-get install openvpn
> modprobe tun
> mknod /dev/net/tun c 10 200
> echo 0 > /proc/sys/net/ipv6/conf/all/forwarding
> echo "echo 1 > /proc/sys/net/ipv6/conf/all/forwarding" > /tmp/up ; chmod a+x /tmp/up
> openvpn --dev-type tap --remote tunnel.lsmod.de 5003 --ifconfig 10.9.0.2
> 255.255.255.0 --dev-node /dev/net/tun --up /tmp/up
> # at this point you can verify your tunnel setup by ping 10.9.0.1
> # on the server I have this: openvpn --dev-type tap --ifconfig 10.9.0.1
> 255.255.255.0 --port 5003 --dev-node /dev/net/tun --float
> # you need UDP port 5003 to pass through your firewall for this
> 
> 
> Alternatively get an user-mode-linux(UML) binary and do something along the
> lines of:
> apt-get install uml-utilities
> TAP=`tunctl -b`
> ifconfig $TAP 192.168.121.1 netmask 255.255.255.252
> echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
> /path/to/linux eth0=tuntap,$TAP ... # booting up to the point where the tap dev
> is really bound (at "ifconfig eth0 192.168.121.2" within the UML)
> tunctl -d $TAP
> 
> 
> After 20 seconds kill the openvpn or linux process.
> This hangs indefinitely, leaving the openvpn process in "D" state.
> syslog states every 10 secs:
> unregister_netdevice: waiting for tap0 to become free.  Usage count = 1
> 
> The kernel will then hang "ifconfig" and "ip" commands, probably because the
> waiting-for-tap0 still holds a mutex.
> 
> After a dozen reboots of trying I found a work-around: replacing the critical
> line with
> (sleep 2 ; echo 1 > /proc/sys/net/ipv6/conf/all/forwarding )&
> 
> A sleep 1 does not suffice.
> Doing the echo before calling openvpn also works fine, so there seems to be a
> timing problem or race condition during initialization of the IPv6 on the newly
> created tap0 device.
> 

Thought to be an ipv6 refcount leak.

           reply	other threads:[~2006-06-19 23:03 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <200606161620.k5GGKagU011416@fire-2.osdl.org>]

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=20060619160620.093eac25.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=bugme-daemon@bugzilla.kernel.org \
    --cc=kernelbmw@lsmod.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox