From owner-freebsd-hackers Wed Jan 14 06:56:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA03963 for hackers-outgoing; Wed, 14 Jan 1998 06:56:20 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from etinc.com ([207.252.1.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA03849 for ; Wed, 14 Jan 1998 06:55:49 -0800 (PST) (envelope-from dennis@etinc.com) Received: from dbsys.etinc.com (dbsys.etinc.com [207.252.1.18]) by etinc.com (8.8.7/8.6.9) with SMTP id JAA13242; Wed, 14 Jan 1998 09:58:03 -0500 (EST) Message-Id: <3.0.32.19980114095929.00f92c20@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 14 Jan 1998 09:59:30 -0500 To: Eivind Eklund From: dennis Subject: Re: FreeBSD Netcards Cc: hackers@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk 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