From owner-freebsd-current@FreeBSD.ORG Thu Sep 18 01:44:19 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 81AB316A4BF for ; Thu, 18 Sep 2003 01:44:19 -0700 (PDT) Received: from firecrest.mail.pas.earthlink.net (firecrest.mail.pas.earthlink.net [207.217.121.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id 971AA43FE5 for ; Thu, 18 Sep 2003 01:44:17 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfk1k.dialup.mindspring.com ([165.247.208.52] helo=mindspring.com) by firecrest.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19zuOL-0000OM-00; Thu, 18 Sep 2003 01:43:57 -0700 Message-ID: <3F697019.1E40CEB1@mindspring.com> Date: Thu, 18 Sep 2003 01:43:05 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John-Mark Gurney References: <20030916102534.J2924@gamplex.bde.org> <24374.1063782444@critter.freebsd.dk> <20030917195203.GA75714@funkthat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4c4bc15e9933a18acf627f38d3f6a9664350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: Poul-Henning Kamp cc: Kris Kennaway cc: ticso@cicely.de cc: current@freebsd.org Subject: Re: panic: Negative bio_offset (-15050100712783872) on bio0xc7725d50 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2003 08:44:19 -0000 John-Mark Gurney wrote: > Bernd Walter wrote this message on Wed, Sep 17, 2003 at 10:27 +0200: > > What is wrong with returning an IO error? > > > > I always hated panics because of filesystem corruptions. > > An alternative would be to just bring that filesystem down. > > Its easy to panic a whole system with a bogus filesystem on a removeable > > media. > > If you're file system is so hosed that it does this, then panicing > is the only safe thing to do. You don't know what continued operation > will do to the filesytem, and you might end up losing more data. > > It is not unresonable to put parameter restrictions on function calls. > It is not much different from enforcing that a pointer is not NULL when > being passed as an argument. There are several reasonable times to do parameter checking: o When your underlying device does not support all the available parameter combinations of your interface, but some other device does (i.e. your device is a subset, and you want to support it anyway, even if it has to offer degraded functionality). o When non-enforcement results in a regression for a third party driver or software package. o When the interface is intended to be a non-fragile one between your code and a third party's code, and you don't trust the third party's code not to cause an error in your code (you could always somewhat work around this one by claiming that the third party software caused an unrecoverable fault in passive voice, the way Microsoft does when VMM32.VXD gives out a pointer and later loses its cookies over seeing it given back). That said, I think that doing parameter checking in functions for interfaces that are non-sparsely implemented underneath is a bad idea, and only damages performance. I have seen this taken to the extreme at a former employer, with disasterous results on performance. -- Terry