Date: Sun, 23 Sep 2001 19:03:46 -0500 From: Jonathan Lemon <jlemon@flugsvamp.com> To: "Matthew N. Dodd" <winter@jurai.net> Cc: Jonathan Lemon <jlemon@flugsvamp.com>, net@freebsd.org Subject: Re: review request. Message-ID: <20010923190346.B79251@prism.flugsvamp.com> In-Reply-To: <Pine.BSF.4.21.0109231951430.3806-100000@sasami.jurai.net> References: <20010923183909.A79251@prism.flugsvamp.com> <Pine.BSF.4.21.0109231951430.3806-100000@sasami.jurai.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Sep 23, 2001 at 07:53:20PM -0400, Matthew N. Dodd wrote: > On Sun, 23 Sep 2001, Jonathan Lemon wrote: > > On Sun, Sep 23, 2001 at 07:32:18PM -0400, Matthew N. Dodd wrote: > > > On Sun, 23 Sep 2001, Jonathan Lemon wrote: > > > > >sys/net/if.c and bpf.c have problems with if_detach() and > > > > >bpfdetach() when they are called with a struct ifnet that has not had > > > > >if_attach() and bpfattach() called on it. Null pointer reference -> > > > > >*boom* etc. > > > > > > > > I would say that this is to be expected. Why is the system calling > > > > the detach functions on a device that isn't attached in the first > > > > place? > > > > > > Driver mistake, but I see no reason why these functions shouldn't handle > > > this gracefully. > > > > Because all it does is conceal the original error. Better to catch > > the mistake and fix the driver than paper it over. > > Right; rather than failing the detach routines will fuss about it so you > know exactly how you screwed up. I don't see this papering anything over. Because this is not a normal operational error. If anything, the statement should be a KASSERT(), but I don't really see the need for it. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010923190346.B79251>