Date: Wed, 14 Jan 1998 09:59:30 -0500 From: dennis <dennis@etinc.com> To: Eivind Eklund <eivind@yes.no> Cc: hackers@FreeBSD.ORG Subject: Re: FreeBSD Netcards Message-ID: <3.0.32.19980114095929.00f92c20@etinc.com>
next in thread | raw e-mail | index | archive | help
At 12:42 AM 1/14/98 +0100, Eivind Eklund wrote: >On Tue, Jan 13, 1998 at 06:36:46PM -0500, dennis wrote: >> At 12:13 AM 1/14/98 +0100, Eivind Eklund wrote: >> >On Tue, Jan 13, 1998 at 06:06:21PM -0500, dennis wrote: >> >> At 02:27 AM 1/13/98 +0100, Eivind Eklund wrote: >> >> >Do you have any other cases of panic() being used incorrectly? >> >> >> >> yeah..go into each director do a "grep panic *.c" ...about half of them >> >> are unnecessary. >> > >> >As far as I've been able to tell (both from working with the kernel >> >previously and by checking now) this is just plain wrong. I'm willing >> >to fix it if you have examples, but I've not yet found any that are >> >clearly wrong. >> >> Depends on your perspective. Should you panic the system if you fail >> to allocate a buffer for a bpf filter? > >During boot: Yes, I think this might be reasonable. You can assume >that if you can't allocate memory during boot, your system can't run >more-or-less at all. If it can run normally, then there is a bug >somewhere during the boot sequence - and kernel bugs _should_ cause >panics. > >> Should ANYTHING having to do with bpf filters crash a system? > >Yes, kernel bugs in relation to bpf should cause panics. > >> If someone tries to send an icmp with an invalid type, should it >> crash the system? > >No, absolutely not. Does it? (With -current, not 2.2.x). A clear and growing problem with the FreeBSD camp is that no one cares about the RELEASES, which is what most of the real world is using. telling me that a bug was fixed in 3.0 in March and still hasnt made it into a release explains why the releases over the past year have been rather disappointing with much of the FreeBSD talent's focus elsewhere. The de driver is another illustration of that. > >> 90% of the panics could print a warning and return without panicing >> the system. I'll bet that the first thing Cisco did when they hacked >> unix into IOS is get rid of the unnecessary crashes. > >Possibly. I think panic() is the right action when you discover a bug >in the kernel that you can't just ignore and can't recover from; >otherwise, getting it fixed is usually a pain. > >> Most of the stuff doesnt happen very often if ever, but its still wrong. > >It is wrong if userland can make a kernel panic, I agree. If kernel >bugs can make the kernel panic, that is OK by me. If an add-on driver makes a bad call a warning should be printed and the operation refused. Its time that FreeBSD recognize that 3rd party software exists (especially with loadable modules) and that errors aren't confined to core team's test beds. Dennis
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.32.19980114095929.00f92c20>