From owner-freebsd-bugs Sun Jun 24 23:10: 7 2001 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id DA50437B409 for ; Sun, 24 Jun 2001 23:10:03 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.3/8.11.3) id f5P6A3B86171; Sun, 24 Jun 2001 23:10:03 -0700 (PDT) (envelope-from gnats) Date: Sun, 24 Jun 2001 23:10:03 -0700 (PDT) Message-Id: <200106250610.f5P6A3B86171@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Bruce Evans Subject: Re: kern/28164: [PATCH] crashdump can trash disklabel/other partitions 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/28164; it has been noted by GNATS. From: Bruce Evans To: Phil Homewood 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