From owner-cvs-src@FreeBSD.ORG Mon Oct 1 12:10:47 2007 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C58316A41B; Mon, 1 Oct 2007 12:10:47 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by mx1.freebsd.org (Postfix) with ESMTP id EED5313C4BF; Mon, 1 Oct 2007 12:10:46 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c220-239-235-248.carlnfd3.nsw.optusnet.com.au [220.239.235.248]) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l91CAamG022347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Oct 2007 22:10:43 +1000 Date: Mon, 1 Oct 2007 22:10:36 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: "Bjoern A. Zeeb" In-Reply-To: <20071001110057.V85753@maildrop.int.zabbadoz.net> Message-ID: <20071001212813.X2796@besplex.bde.org> References: <200709241339.l8ODd6k6059694@repoman.freebsd.org> <47002674.8050707@tomjudge.com> <47002E2F.3030306@tomjudge.com> <20071001090547.H85753@maildrop.int.zabbadoz.net> <20071001201359.M2557@besplex.bde.org> <20071001110057.V85753@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org, Bruce Evans Subject: Re: cvs commit: src/sys/ufs/ffs ffs_alloc.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2007 12:10:47 -0000 On Mon, 1 Oct 2007, Bjoern A. Zeeb wrote: > On Mon, 1 Oct 2007, Bruce Evans wrote: > >> On Mon, 1 Oct 2007, Bjoern A. Zeeb wrote: >>>> s/fis/fix/ >>> >>> yes it should. I closed the PR, See the comment there. >> >> s/fix/work around/ >> >> The bug is in newfs and tunefs permitting garbage parameters, so it cannot >> be fixed in ffs_alloc.c. > > No matter what iput the kernel gets and from where, it MUST NOT (or at > least SHOULD not;) panic unless explicitly request by KASSERT/panic/.. Not quite true. There are hundreds or thousands of sysctls that can be used to set critical parameters to garbage which will cause a panic. Bounds checking for sysctl parameters is almost completely absent, and this is sometimes useful for investigating the limits of useful parameters without rebuilding the kernel. Also, a division by zero trap is preferable to a panic since it is restartable. > So this commit fixes a DIV0 bug in the kernel. > > Of course you are right, that the values should be checked by the tools > that we have in the tree so that this problem would not occur. > We could even check if the values given make sense at all, but that still > is a different story to a kernel panic. You deleted the part where I said where the fix belongs in the kernel (next to related fixups). ffs does almost no runtime checking by design. It depends on fsck or mount-time fixups doing all the necessary checking and fixups, so that the main code can be simpler and faster. New code shouldn't do things differently. Bruce