Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Mar 2001 09:44:54 -0800 (PST)
From:      Archie Cobbs <archie@dellroad.org>
To:        Yar Tikhiy <yar@comp.chem.msu.su>
Cc:        Archie Cobbs <archie@dellroad.org>, freebsd-stable@FreeBSD.ORG, freebsd-net@FreeBSD.ORG
Subject:   Re: Kernel Panic on 4.3-RC #0 using PPPoE
Message-ID:  <200103281744.f2SHisC47244@arch20m.dellroad.org>
In-Reply-To: <20010328113049.B28919@comp.chem.msu.su> "from Yar Tikhiy at Mar 28, 2001 11:30:49 am"

next in thread | previous in thread | raw e-mail | index | archive | help
Yar Tikhiy writes:
> > Mike Tancsa writes:
> > > >Not sure why this hasn't been detected before though. Below is
> > > >a possible patch.
> > > 
> > > It has been at http://www.freebsd.org/cgi/query-pr.cgi?pr=25478 and 
> > > discussed a few times in freebsd-net.
> > 
> > Here is the better (?) patch. I'd like to commit this if nobody
> > objects..
> 
> Please take a careful look at the frames 6 through 9 of the stack
> trace in PR#25478, so you may notice that your patch happens to do
> nothing about the broblem.  You are going to add a check for IFF_UP
> to ether_output_frame() while that function is just a bottom half
> of ether_output(), which does do the check at its very beginning.
> 
> The real problem is that ethernet card drivers rely on ether_output()
> making sure they are up before calling their if_output()s. AFAIK
> the vlan driver is the only piece of code where the standard
> ether_output()->if_output() order is bypassed, and an if_output()
> routine of an ethernet card is called directly. Therefore, the
> IFF_UP check should be in the vlan code, and I'm going to commit
> a corresponding fix (PR: kern/22179). Any objections?

Yes that's slightly different from the problem I was trying to
fix (crash in if_fxp.c using PPPoE). We would need both fixes.

Hmm..

So VLAN and PPPoE have in common that they both result in packets
reaching the interface output routine without IFF_UP -- via two
different code paths.

Now the question is, should we add an IFF_UP check to all of the
places that (eventually) call driver output routines, or should we
change all the drivers to make them not panic (perhaps just return)
if IFF_UP is not set?

The existing semantics seem to allow a driver to assume that
its output routine will be called ONLY if IFF_UP, so the first
approach would be consistent with that... but the second approach
is a more robust solution to the problem (who knows what other
things like VLAN and netgraph may appear in the future?).

-Archie

__________________________________________________________________________
Archie Cobbs     *     Packet Design     *     http://www.packetdesign.com

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103281744.f2SHisC47244>