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