From: ebiederm@xmission.com (Eric W. Biederman)
To: David Woodhouse <dwmw2@infradead.org>
Cc: netdev@vger.kernel.org, johannes@sipsolutions.net
Subject: Re: tun netns BUG()
Date: Fri, 05 Jun 2009 16:24:29 -0700 [thread overview]
Message-ID: <m1ljo61cya.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <1244193463.3751.129.camel@macbook.infradead.org> (David Woodhouse's message of "Fri\, 05 Jun 2009 10\:17\:43 +0100")
The patch below fixes the one bug I know of in with just my changes
applied. I don't think it fixes everything with Herberts changes.
I expect some of this will need to be moved to release to fix the
select problem on 2.6.30-rc8.
Eric
From: Eric W. Biederman <ebiederm@aristanetworks.com>
Subject: [PATCH] tun: Fix unregister race
It is possible for tun_chr_close to race with dellink on the
a tun device. In which case if __tun_get runs before dellink
but dellink runs before tun_chr_close calls unregister_netdevice
we will attempt to unregister the netdevice after it is already
gone.
The two cases are already serialized on the rtnl_lock, so I have
gone for the cheap simple fix of moving rtnl_lock to cover __tun_get
in tun_chr_close. Eliminating the possibility of the tun device
being unregistered between __tun_get and unregister_netdevice in
tun_chr_close.
Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com>
---
--- linux-2.6.28.x86_64-old/drivers/net/tun.c 2009-05-06 15:01:56.000000000 -0700
+++ linux-2.6.28.x86_64/drivers/net/tun.c 2009-05-06 15:10:09.000000000 -0700
@@ -1194,21 +1194,22 @@
static int tun_chr_close(struct inode *inode, struct file *file)
{
struct tun_file *tfile = file->private_data;
- struct tun_struct *tun = __tun_get(tfile);
+ struct tun_struct *tun;
+ rtnl_lock();
+ tun = __tun_get(tfile);
if (tun) {
DBG(KERN_INFO "%s: tun_chr_close\n", tun->dev->name);
- rtnl_lock();
__tun_detach(tun);
/* If desireable, unregister the netdevice. */
if (!(tun->flags & TUN_PERSIST))
unregister_netdevice(tun->dev);
- rtnl_unlock();
}
+ rtnl_unlock();
put_net(tfile->net);
kfree(tfile);
next prev parent reply other threads:[~2009-06-05 23:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-04 19:05 tun netns BUG() David Woodhouse
2009-06-05 1:19 ` Eric W. Biederman
2009-06-05 8:42 ` David Woodhouse
2009-06-05 9:17 ` David Woodhouse
2009-06-05 23:24 ` Eric W. Biederman [this message]
2009-06-06 7:06 ` David Woodhouse
2009-06-08 7:44 ` David Miller
2009-07-03 8:35 ` Herbert Xu
2009-07-03 9:03 ` Herbert Xu
2009-07-03 14:52 ` Eric W. Biederman
2009-07-03 15:25 ` Herbert Xu
2009-07-06 2:01 ` David Miller
2009-06-05 23:20 ` Eric W. Biederman
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=m1ljo61cya.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=dwmw2@infradead.org \
--cc=johannes@sipsolutions.net \
--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.