kern/63772: tap device / exclusive open problem

Stefan `Sec` Zehl sec at 42.org
Tue Mar 9 00:36:50 PST 2004


On Mon, Mar 08, 2004 at 17:24 -0800, Brooks Davis wrote:
> The problem is very simple.  Since !(tp->tap_flags & TAP_OPEN) should
> never happen (and results in a panic in the KASSERT if INVARIANTS is
> enabled) your "fix" effectivly removes the entire rest of this
> function.  It may be that the rest of that code is junk, but if that's
> the case, it should be removed not bypassed by a bogus conditional.

Aww. I see. I feel so stupid. Somehow I didn't realize that the
condition inside the KASSERT was the exact opposite of my added
condition. Thanks for pointing out the obvious.

However, you made a mistake, too :)

> With this patch and INVARIANTS, you end up with:
> 
> function()
> {
> 	...
> 	if (!A)
> 		panic;
> 	if (A)
> 		return (EBUSY)
> }

No. Kassert panics if the argument is false, not if it is true.

|     KASSERT(!(tp->tap_flags & TAP_OPEN), 
| 	    ("%s flags is out of sync", tp->tap_if.if_xname));
| 
|     if (tp->tap_flags & TAP_OPEN)
| 	    return (EBUSY);

and from sys/systm.h:

| #define KASSERT(exp,msg) do { \
|         if (__predict_false(!(exp))) \
|                 panic msg; \
| } while (0)

Lucky for me, i didn't have INVARIANTS defined :)

If I'm correct, a kernel with INVARIANTS and if_tap loaded can be
panic()ed by a simple "cat /dev/tun0 & cat /dev/tun0".

After my embarrassing dsplay of stupidity, i will however test this
tonight on a test box, and report back on my findings.

CU,
    Sec
-- 
The problem with troubleshooting is that trouble shoots back.


More information about the freebsd-bugs mailing list