The "tun?" dev need not be opened at all. One is allowed to perform

the following operations, e.g.:
1) ifconfig tun0 create
2) ifconfig tun0 10.1.1.1 10.1.1.2
3) route add -net 192.103.54.0/24 -iface tun0
4) ifconfig tun0 destroy
If cv wait on the TUN_CLOSED flag, then the last operation (4) will
block forever.

Revert the previous changes and fix the mtx_unlock() leak.
This commit is contained in:
qingli 2008-12-25 22:32:32 +00:00
parent 6a15aa1665
commit 2a933d7a9b

View File

@ -79,7 +79,6 @@ struct tun_softc {
#define TUN_RWAIT 0x0040
#define TUN_ASYNC 0x0080
#define TUN_IFHEAD 0x0100
#define TUN_CLOSED 0x0200
#define TUN_READY (TUN_OPEN | TUN_INITED)
@ -257,11 +256,11 @@ tun_destroy(struct tun_softc *tp)
/* Unlocked read. */
mtx_lock(&tp->tun_mtx);
if ((tp->tun_flags & (TUN_OPEN|TUN_CLOSED)) != TUN_CLOSED)
if ((tp->tun_flags & TUN_OPEN) != 0)
cv_wait_unlock(&tp->tun_cv, &tp->tun_mtx);
else
mtx_unlock(&tp->tun_mtx);
CURVNET_SET(TUN2IFP(tp)->if_vnet);
dev = tp->tun_dev;
bpfdetach(TUN2IFP(tp));
@ -500,7 +499,6 @@ tunclose(struct cdev *dev, int foo, int bar, struct thread *td)
KNOTE_UNLOCKED(&tp->tun_rsel.si_note, 0);
TUNDEBUG (ifp, "closed\n");
tp->tun_flags |= TUN_CLOSED;
cv_broadcast(&tp->tun_cv);
mtx_unlock(&tp->tun_mtx);
return (0);