kern/63772: tap device / exclusive open problem
brooks at one-eyed-alien.net
Mon Mar 8 17:24:46 PST 2004
On Mon, Mar 08, 2004 at 04:50:14PM -0800, Stefan `Sec` Zehl wrote:
> The following reply was made to PR kern/63772; it has been noted by GNATS.
> From: Stefan `Sec` Zehl <sec at 42.org>
> To: Brooks Davis <brooks at one-eyed-alien.net>
> Cc: FreeBSD-gnats-submit at freebsd.org, freebsd-bugs at freebsd.org
> Subject: Re: kern/63772: tap device / exclusive open problem
> Date: Tue, 9 Mar 2004 01:46:45 +0100
> On Fri, Mar 05, 2004 at 10:55 -0800, Brooks Davis wrote:
> > > 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);
> > > +
> > There's obviously something complicated going on since with INVARIANTS
> > enabled this would either return EBUSY or panic. This should definitely
> > not be committed as is.
> I must admit, I don't understand the problem. this is an really simple
> if. Nothing is modified, and tp is not NULL, or the KASSERT above would
> be broken already.
> How do you get it to panic?
> It works fine for me.
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.
With this patch and INVARIANTS, you end up with:
This demonstrates a lack of sufficent understanding of the code so while
I believe that it works for you, it should not be commited as is.
Creating unreachable code is not a good idea.
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-bugs/attachments/20040308/ec44cfbe/attachment.bin
More information about the freebsd-bugs