From owner-freebsd-stable  Wed Mar 28 10: 0:33 2001
Delivered-To: freebsd-stable@freebsd.org
Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26])
	by hub.freebsd.org (Postfix) with ESMTP
	id 002CF37B722; Wed, 28 Mar 2001 10:00:17 -0800 (PST)
	(envelope-from archie@dellroad.org)
Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20])
	by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id JAA45344;
	Wed, 28 Mar 2001 09:45:33 -0800 (PST)
Received: (from archie@localhost)
	by arch20m.dellroad.org (8.11.1/8.11.1) id f2SHisC47244;
	Wed, 28 Mar 2001 09:44:54 -0800 (PST)
	(envelope-from archie)
From: Archie Cobbs <archie@dellroad.org>
Message-Id: <200103281744.f2SHisC47244@arch20m.dellroad.org>
Subject: Re: Kernel Panic on 4.3-RC #0 using PPPoE
In-Reply-To: <20010328113049.B28919@comp.chem.msu.su> "from Yar Tikhiy at Mar
 28, 2001 11:30:49 am"
To: Yar Tikhiy <yar@comp.chem.msu.su>
Date: Wed, 28 Mar 2001 09:44:54 -0800 (PST)
Cc: Archie Cobbs <archie@dellroad.org>, freebsd-stable@FreeBSD.ORG,
	freebsd-net@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL82 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Sender: owner-freebsd-stable@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

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