Date: Sun, 24 Jun 2001 23:10:03 -0700 (PDT) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/28164: [PATCH] crashdump can trash disklabel/other partitions Message-ID: <200106250610.f5P6A3B86171@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/28164; it has been noted by GNATS. From: Bruce Evans <bde@zeta.org.au> To: Phil Homewood <pdh@lineo.com> Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: kern/28164: [PATCH] crashdump can trash disklabel/other partitions Date: Mon, 25 Jun 2001 16:02:09 +1000 (EST) On Mon, 25 Jun 2001, Phil Homewood wrote: > Bruce Evans wrote: > > This did not repeat it for me :-). > ... > OK, more info, see dmesg attached. Thanks. > > I don't see how these patches can help. The first hunk prevents dumping > > ... > > the first hunk adjusts the dump start down). It also has bad side effects: > > - it causes 2 nonexistent pages to be dumped. This might cause NMIs or > > worse. > > Erm, no, it doesn't. Unless I'm missing something, it just causes an extra > two pages of disk to be required for the dump. Yes, this is wrong, there's I think you're missing that `*count' is an output parameter. Something must be written to the extra space, and that something is extra pages beyond what `Maxmem' says is the end of memory. > Second attachment is a disklabel of the disk containing the dumpdev. > The critical size for da1s2b is 524298 blocks; at that size the dump > works, but at 524297 blocks it trashes the label. > # /dev/da1s2c: > type: SCSI > disk: da1s2 > ... > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > b: 526336 0 swap # (Cyl. 0 - 256) > c: 35317760 0 unused 0 0 # (Cyl. 0 - 17244) > e: 34791424 526336 4.2BSD 1024 8192 16 # (Cyl. 257 - 17244) I think you are just trashing the label becauses it is inside da1s2b, not overrunning da1s2b. This is certainly a bug. The label is write protected in software, but the dump routines don't even know that the label is there. This bug is not seen in most configurations because the dump partition usually starts at a nonzero offset. Untested incomplete fixes (the boot block area should also be protected...): Index: kern_shutdown.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_shutdown.c,v retrieving revision 1.101 diff -u -2 -r1.101 kern_shutdown.c --- kern_shutdown.c 2001/04/29 02:44:48 1.101 +++ kern_shutdown.c 2001/06/25 06:00:08 @@ -431,5 +431,5 @@ */ newdumplo = psize - Maxmem * PAGE_SIZE / DEV_BSIZE; - if (newdumplo < 0) + if (newdumplo <= LABELSECTOR) return (ENOSPC); dumpdev = dev; Index: subr_disk.c =================================================================== RCS file: /home/ncvs/src/sys/kern/subr_disk.c,v retrieving revision 1.41 diff -u -2 -r1.41 subr_disk.c --- subr_disk.c 2001/05/29 18:19:57 1.41 +++ subr_disk.c 2001/06/25 06:00:24 @@ -156,5 +156,5 @@ return (ENXIO); *count = (u_long)Maxmem * PAGE_SIZE / dl->d_secsize; - if (dumplo < 0 || + if (dumplo <= LABELSECTOR || (dumplo + *count > dl->d_partitions[dkpart(dev)].p_size)) return (EINVAL); 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?200106250610.f5P6A3B86171>