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 [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
