Date: Tue, 26 Nov 2002 23:40:02 -0800 (PST) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/45777: crashdump issue with too-small dumpdev Message-ID: <200211270740.gAR7e2qh078493@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/45777; it has been noted by GNATS. From: Bruce Evans <bde@zeta.org.au> To: Dan Nelson <dnelson@allantgroup.com> Cc: FreeBSD-gnats-submit@FreeBSD.ORG, <phk@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200211270740.gAR7e2qh078493>