From owner-freebsd-bugs Tue Nov 26 23:40: 5 2002 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8587637B401 for ; Tue, 26 Nov 2002 23:40:03 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 210E243E9C for ; Tue, 26 Nov 2002 23:40:03 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.6/8.12.6) with ESMTP id gAR7e2x3078494 for ; Tue, 26 Nov 2002 23:40:02 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.6/8.12.6/Submit) id gAR7e2qh078493; Tue, 26 Nov 2002 23:40:02 -0800 (PST) Date: Tue, 26 Nov 2002 23:40:02 -0800 (PST) Message-Id: <200211270740.gAR7e2qh078493@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Bruce Evans Subject: Re: kern/45777: crashdump issue with too-small dumpdev Reply-To: Bruce Evans Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR kern/45777; it has been noted by GNATS. From: Bruce Evans To: Dan Nelson Cc: FreeBSD-gnats-submit@FreeBSD.ORG, Subject: Re: kern/45777: crashdump issue with too-small dumpdev Date: Wed, 27 Nov 2002 18:45:02 +1100 (EST) On Tue, 26 Nov 2002, Dan Nelson wrote: > >Description: > > I finally discovered why I have never been able to get crashdumps to > work: at some point all error-checking in the dump routines > disappeared. I happen to have 1 GB of RAM, and 640MB of swap (old > system, and I never reformatted after adding RAM). It disappeared in rev.1.132 of kern_shutdown.c. brian fixed the case of devices of size 0 in rev.1.60 of subr_disk.c. > dumpon lets me set the dump device to my teeny 640MB swap partition, > and when it comes time to dump, dumpsys calculates > > dumplo = di->mediaoffset + di->mediasize - Maxmem * (off_t)PAGE_SIZE; > > which in my case ends up being a negative number. The dump ends up > failing when it tries to write to a negative block number and the SCSI > drive refuses the request. So it seems like there are three bugs here: > 1 - /sbin/dumpon doesn't verify RAM size against raw device size. This > may be forgivable, as neither is all that easy to calculate from > userland. It makes a syscall that can do it, but the syscall never bothered because the dump device (size) may change after it has been checked. It would just be nice for /sbin/dumpon to warn if the device is too small and for something to warn if the dump device size changes. OTOH, I consider even the existence of /sbin/dumpon to be overengineering. In its current form it does nothing that the sysctl couldn't do (early versions of the sysctl couldn't print the device name). > 2 - ioctl(DIOCSKERNELDUMP) lets me set my dump device to something > smaller than maxmem. > > 3 - dumpsys doesn't range-check its calculations. 4 - dumpsys has lost even its primitive understanding of leaving space for metadata. > I'm just lucky I don't have a 384MB root partition, or the first time I > pancied I would have overwritten my root :) That would be good luck too. The worst case is overwriting a large non-FreeBSD filesystem which is not owned by you. It can happen that the final offset is nonnegative but di->mediasize - Maxmem * (off_t)PAGE_SIZE is negative. Then a slice or partition other than the dump device slice is scribbled on (brian fixed a special case of this). Or di->mediasize - Maxmem * (off_t)PAGE_SIZE may be small. Then metadata (boot blocks and/or label) is scribbled on. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message