Date: Fri, 4 Jun 1999 18:37:08 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Garance A Drosihn <drosih@rpi.edu> Cc: Greg Black <gjb@acm.org>, "David E. Cross" <crossd@cs.rpi.edu>, freebsd-hackers@FreeBSD.ORG Subject: Re: 3.2-stable, panic #12 Message-ID: <199906050137.SAA10480@apollo.backplane.com> References: <199906031735.NAA37037@cs.rpi.edu> of Thu, 03 Jun 1999 13:35:19 -0400 <199906031735.NAA37037@cs.rpi.edu> <v04011708b37ddb8b01bb@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
:> Since this opens the file so that it cannot be written to, not
:> to mention the really weird mode it will get if it's created by
:> that open(), the rest of the thing doesn't deserve to work.
:>
:> Generally speaking, it's a good idea to make sure that test code
:> is at least decent before starting to puzzle over what it does.
:
:So, are you saying that it is perfectly reasonable that this
:less-than-pretty user-written code, running on remote machines,
:and requiring absolutely no special privs, will crash FreeBSD
:used as an NFS server?
:
:I don't care if the code "works", or SEGV's, or if the user is
:logged off for being stupid, but I really do not think it is
:acceptable for the *file-server* to crash. The odd parameters
:to open() probably explains why some code-path in the system
:is getting confused, but it is still the OS's responsibility
:to keep running even when users do odd things.
:
:---
:Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu
:Senior Systems Programmer or drosih@rpi.edu
:Rensselaer Polytechnic Institute
In regards to test code: It doesn't matter whether the test code
is reasonable or not. The purpose of the test code is to cause
the kernel to reveal a bug in order to make it easyier to fix the bug.
Frankly, I wish people could give me such simple and straightforward
test code more often!
Many of the remaining kernel bugs are race conditions. These sorts of
bugs are really annoying to track down because they usually only screw
the machine up once in a blue moon. In some cases (as in the above
case) they screw the machine up more regularly due to operational
characteristics of the particular system. Test programs that are able to
reproduce the conditions can often be straightforward but very odd
looking. They do not have to mimic real life: the idea is to accellerate
the generation of the bug so it occurs in minutes rather then days.
In regards to the kernel: Kernels should not crash, period. Test
programs that are able to crash a kernel are always desireable. Now,
obviously, there are ways to crash the kernel through resource starvation.
We want to eventually fix even these situations. The most important
bugs are the ones generated from race conditions and those are the ones
where test programs are the most desireable because it is damn hard to
reproduce some of those bugs based on a text description.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906050137.SAA10480>