From pdh@moreton.com.au  Thu Jun 14 21:54:53 2001
Return-Path: <pdh@moreton.com.au>
Received: from dorfl.internal.moreton.com.au (ppp4.adsl238.pacific.net.au [203.143.238.4])
	by hub.freebsd.org (Postfix) with ESMTP id 4268B37B409
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 14 Jun 2001 21:54:51 -0700 (PDT)
	(envelope-from pdh@moreton.com.au)
Received: (from pdh@localhost)
	by dorfl.internal.moreton.com.au (8.11.4/8.11.4) id f5F4shQ00570;
	Fri, 15 Jun 2001 14:54:43 +1000 (EST)
	(envelope-from pdh)
Message-Id: <200106150454.f5F4shQ00570@dorfl.internal.moreton.com.au>
Date: Fri, 15 Jun 2001 14:54:43 +1000 (EST)
From: Phil Homewood <pdh@moreton.com.au>
Reply-To: Phil Homewood <pdh@moreton.com.au>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: [PATCH] crashdump can trash disklabel/other partitions
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         28164
>Category:       kern
>Synopsis:       [PATCH] crashdump can trash disklabel/other partitions
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Jun 14 22:00:07 PDT 2001
>Closed-Date:    Sun Dec 2 16:39:25 PST 2001
>Last-Modified:  Sun Dec 02 16:40:38 PST 2001
>Originator:     Phil Homewood
>Release:        FreeBSD 4.3-STABLE i386
>Organization:
>Environment:
System: FreeBSD dorfl.internal.moreton.com.au 4.3-STABLE FreeBSD 4.3-STABLE #7: Fri Jun 15 11:14:57 EST 2001 root@:/usr/obj/usr/src/sys/DORFL i386


	
>Description:
	Crashdumps can overwrite the last few blocks of the device
	immediately before the dumpdev, if the dumpdev is approximately
	the same size as physical memory.

>How-To-Repeat:
	Set up a swap device of the same size as physical memory and
	force a crashdump (eg, from DDB).

>Fix:

	The following patch works but is probably incorrect (in tests
	on this machine, I needed an extra 10 blocks of disk space, and
	one page of physical memory requires 8 blocks of disk).
	Someone with a better understanding than I have should review
	this patch, but it should provide a good starting point.



--- kern/kern_shutdown.c.orig	Mon Jun 11 23:12:10 2001
+++ kern/kern_shutdown.c	Fri Jun 15 14:46:53 2001
@@ -421,7 +421,7 @@
 	/*
 	 * XXX should clean up checking in dumpsys() to be more like this.
 	 */
-	newdumplo = psize - Maxmem * PAGE_SIZE / DEV_BSIZE;
+	newdumplo = psize - (Maxmem + 2) * PAGE_SIZE / DEV_BSIZE;
 	if (newdumplo < 0)
 		return (ENOSPC);
 	dumpdev = dev;
--- kern/subr_disk.c.orig	Fri Jun  1 02:47:45 2001
+++ kern/subr_disk.c	Fri Jun 15 14:46:53 2001
@@ -91,7 +91,7 @@
 	dl = dsgetlabel(dev, dp->d_slice);
 	if (!dl)
 		return (ENXIO);
-	*count = (u_long)Maxmem * PAGE_SIZE / dl->d_secsize;
+	*count = (u_long)(Maxmem + 2) * PAGE_SIZE / dl->d_secsize;
 	if (dumplo < 0 || 
 	    (dumplo + *count > dl->d_partitions[dkpart(dev)].p_size))
 		return (EINVAL);
>Release-Note:
>Audit-Trail:

From: Bruce Evans <bde@zeta.org.au>
To: Phil Homewood <pdh@moreton.com.au>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/28164: [PATCH] crashdump can trash disklabel/other partitions
Date: Fri, 22 Jun 2001 22:31:24 +1000 (EST)

 On Fri, 15 Jun 2001, Phil Homewood wrote:
 
 > >Description:
 > 	Crashdumps can overwrite the last few blocks of the device
 > 	immediately before the dumpdev, if the dumpdev is approximately
 > 	the same size as physical memory.
 > 
 > >How-To-Repeat:
 > 	Set up a swap device of the same size as physical memory and
 > 	force a crashdump (eg, from DDB).
 
 This did not repeat it for me :-).
 
 > >Fix:
 > 
 > 	The following patch works but is probably incorrect (in tests
 > 	on this machine, I needed an extra 10 blocks of disk space, and
 > 	one page of physical memory requires 8 blocks of disk).
 > 	Someone with a better understanding than I have should review
 > 	this patch, but it should provide a good starting point.
 > 
 > --- kern/kern_shutdown.c.orig	Mon Jun 11 23:12:10 2001
 > +++ kern/kern_shutdown.c	Fri Jun 15 14:46:53 2001
 > @@ -421,7 +421,7 @@
 >  	/*
 >  	 * XXX should clean up checking in dumpsys() to be more like this.
 >  	 */
 > -	newdumplo = psize - Maxmem * PAGE_SIZE / DEV_BSIZE;
 > +	newdumplo = psize - (Maxmem + 2) * PAGE_SIZE / DEV_BSIZE;
 >  	if (newdumplo < 0)
 >  		return (ENOSPC);
 >  	dumpdev = dev;
 > --- kern/subr_disk.c.orig	Fri Jun  1 02:47:45 2001
 > +++ kern/subr_disk.c	Fri Jun 15 14:46:53 2001
 > @@ -91,7 +91,7 @@
 >  	dl = dsgetlabel(dev, dp->d_slice);
 >  	if (!dl)
 >  		return (ENXIO);
 > -	*count = (u_long)Maxmem * PAGE_SIZE / dl->d_secsize;
 > +	*count = (u_long)(Maxmem + 2) * PAGE_SIZE / dl->d_secsize;
 >  	if (dumplo < 0 || 
 >  	    (dumplo + *count > dl->d_partitions[dkpart(dev)].p_size))
 >  		return (EINVAL);
 
 I don't see how these patches can help.  The first hunk prevents dumping
 if the device size (in bytes) is precisely the same as the memory size
 (according to Maxmem).  But dumping will still occur if the device size is
 2 pages larger, and then the second hunk almost ensures that any overrun
 still occurs (since it adjusts the dump size up by the same amount that
 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.
 - it causes overflow on machines with 4GB less 2 pages of memory instead
   of only on machines with 4GB of memory, if Maxmem can reach 4GB.  Better
   original code:
 
 	*count = (u_long)Maxmem * (PAGE_SIZE / dl->d_secsize);
 
   This assumes that PAGE_SIZE is a multiple of dl->d_secsize, but all dump
   routines already assume this.
 
 The patch might help by avoidng rounding bugs in the dump routines (e.g.,
 they might round *count up to a multiple of 128, so it's best to have
 *count a multiple of 128 to begin with), but I couldn't see any bugs like
 that.
 
 Bruce
 

From: Phil Homewood <pdh@lineo.com>
To: Bruce Evans <bde@zeta.org.au>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/28164: [PATCH] crashdump can trash disklabel/other partitions
Date: Mon, 25 Jun 2001 10:54:23 +1000

 --pWyiEgJYm5f9v55/
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 Bruce Evans wrote:
 > > >How-To-Repeat:
 > > 	Set up a swap device of the same size as physical memory and
 > > 	force a crashdump (eg, from DDB).
 > 
 > This did not repeat it for me :-).
 
 Hmm.
 
 OK, more info, see dmesg attached.
 
 > I don't see how these patches can help.  The first hunk prevents dumping
 > if the device size (in bytes) is precisely the same as the memory size
 > (according to Maxmem).  But dumping will still occur if the device size is
 > 2 pages larger, and then the second hunk almost ensures that any overrun
 > still occurs (since it adjusts the dump size up by the same amount that
 > 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
 no logical reason I can see for that number, but I just wanted to give
 some kind of starting point...
 
 > - it causes overflow on machines with 4GB less 2 pages of memory instead
 >   of only on machines with 4GB of memory, if Maxmem can reach 4GB.  Better
 >   original code:
 > 
 > 	*count = (u_long)Maxmem * (PAGE_SIZE / dl->d_secsize);
 > 
 >   This assumes that PAGE_SIZE is a multiple of dl->d_secsize, but all dump
 >   routines already assume this.
 > 
 > The patch might help by avoidng rounding bugs in the dump routines (e.g.,
 > they might round *count up to a multiple of 128, so it's best to have
 > *count a multiple of 128 to begin with), but I couldn't see any bugs like
 > that.
 
 I can probably use this machine for another couple of days if you want
 me to do some more testing/debugging of this problem. (It's due to go
 production real soon.) I couldn't understand why the dump was
 overflowing at all, I just needed it to stop doing so. :-)
 
 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.
 
 --pWyiEgJYm5f9v55/
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: attachment; filename="dmesg.boot"
 
 Copyright (c) 1992-2001 The FreeBSD Project.
 Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
 	The Regents of the University of California. All rights reserved.
 FreeBSD 4.3-STABLE #0: Fri Jun 15 15:53:56 EST 2001
     root@dorfl.internal.moreton.com.au:/usr/obj/usr/src/sys/DORFL
 Timecounter "i8254"  frequency 1193182 Hz
 CPU: AMD Athlon(tm) Processor (1299.38-MHz 686-class CPU)
   Origin = "AuthenticAMD"  Id = 0x642  Stepping = 2
   Features=0x183f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR>
   AMD Features=0xc0440000<<b18>,AMIE,DSP,3DNow!>
 real memory  = 268435456 (262144K bytes)
 avail memory = 257634304 (251596K bytes)
 Preloaded elf kernel "kernel" at 0xc038d000.
 Pentium Pro MTRR support enabled
 md0: Malloc disk
 npx0: <math processor> on motherboard
 npx0: INT 16 interface
 pcib0: <Host to PCI bridge> on motherboard
 pci0: <PCI bus> on pcib0
 pcib2: <PCI to PCI bridge (vendor=1106 device=8305)> at device 1.0 on pci0
 pci1: <PCI bus> on pcib2
 pci1: <S3 Trio3D/2X graphics accelerator> at 0.0
 isab0: <VIA 82C686 PCI-ISA bridge> at device 7.0 on pci0
 isa0: <ISA bus> on isab0
 atapci0: <VIA 82C686 ATA100 controller> port 0xc000-0xc00f at device 7.1 on pci0
 ata0: at 0x1f0 irq 14 on atapci0
 ata1: at 0x170 irq 15 on atapci0
 chip2: <VIA 82C686 AC97 Audio> port 0xd400-0xd403,0xd000-0xd003,0xcc00-0xccff irq 12 at device 7.5 on pci0
 ahc0: <Adaptec 29160 Ultra160 SCSI adapter> port 0xdc00-0xdcff mem 0xdd000000-0xdd000fff irq 11 at device 8.0 on pci0
 aic7892: Wide Channel A, SCSI Id=7, 32/255 SCBs
 ed0: <NE2000 PCI Ethernet (KTI)> port 0xe000-0xe01f irq 10 at device 9.0 on pci0
 ed0: address 00:40:f6:0c:35:7a, type NE2000 (16 bit) 
 pcib1: <Host to PCI bridge> on motherboard
 pci2: <PCI bus> on pcib1
 fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
 fdc0: FIFO enabled, 8 bytes threshold
 fd0: <1440-KB 3.5" drive> on fdc0 drive 0
 atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
 vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
 sc0: <System console> at flags 0x100 on isa0
 sc0: VGA <16 virtual consoles, flags=0x100>
 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
 sio0: type 16550A, console
 sio1 at port 0x2f8-0x2ff irq 3 on isa0
 sio1: type 16550A
 ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0
 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode
 ppi0: <Parallel I/O> on ppbus0
 plip0: <PLIP network interface> on ppbus0
 lpt0: <Printer> on ppbus0
 lpt0: Interrupt-driven port
 acd0: CDROM <SAMSUNG CD-ROM SC-152C> at ata1-master using PIO4
 Waiting 5 seconds for SCSI devices to settle
 Mounting root from ufs:/dev/da0s1a
 da0 at ahc0 bus 0 target 0 lun 0
 da0: <IBM DDYS-T18350N S96H> Fixed Direct Access SCSI-3 device 
 da0: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled
 da0: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C)
 da1 at ahc0 bus 0 target 1 lun 0
 da1: <IBM DDYS-T18350N S96H> Fixed Direct Access SCSI-3 device 
 da1: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled
 da1: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C)
 da2 at ahc0 bus 0 target 2 lun 0
 da2: <IBM DDYS-T18350N S96H> Fixed Direct Access SCSI-3 device 
 da2: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled
 da2: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C)
 
 --pWyiEgJYm5f9v55/
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: attachment; filename=disklabel-da1s2
 
 # /dev/da1s2c:
 type: SCSI
 disk: da1s2
 label: 
 flags:
 bytes/sector: 512
 sectors/track: 32
 tracks/cylinder: 64
 sectors/cylinder: 2048
 cylinders: 17245
 sectors/unit: 35317760
 rpm: 3600
 interleave: 1
 trackskew: 0
 cylinderskew: 0
 headswitch: 0		# milliseconds
 track-to-track seek: 0	# milliseconds
 drivedata: 0 
 
 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)
 
 --pWyiEgJYm5f9v55/--

From: Phil Homewood <pdh@lineo.com>
To: Bruce Evans <bde@zeta.org.au>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/28164: [PATCH] crashdump can trash disklabel/other partitions
Date: Mon, 25 Jun 2001 10:58:16 +1000

 Phil Homewood wrote:
 > 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.
 
 I forgot to mention: da1s2 is, of course, the second slice on the
 disk, if that makes any difference:
 
 
 ******* Working on device /dev/da1 *******
 parameters extracted from in-core disklabel are:
 cylinders=17501 heads=64 sectors/track=32 (2048 blks/cyl)
 
 Figures below won't work with BIOS for partitions not in cyl 1
 parameters to be used for BIOS calculations are:
 cylinders=17501 heads=64 sectors/track=32 (2048 blks/cyl)
 
 Media sector size is 512
 Warning: BIOS sector numbering starts with sector 1
 Information from DOS bootblock is:
 The data for partition 1 is:
 sysid 165,(FreeBSD/NetBSD/386BSD)
     start 32, size 524256 (255 Meg), flag 0
 	beg: cyl 0/ sector 1/ head 1;
 	end: cyl 255/ sector 32/ head 63
 The data for partition 2 is:
 sysid 165,(FreeBSD/NetBSD/386BSD)
     start 524288, size 35317760 (17245 Meg), flag 0
 	beg: cyl 256/ sector 1/ head 0;
 	end: cyl 1023/ sector 32/ head 63
 The data for partition 3 is:
 <UNUSED>
 The data for partition 4 is:
 <UNUSED>

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
 

From: Phil Homewood <pdh@lineo.com>
To: Bruce Evans <bde@zeta.org.au>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/28164: [PATCH] crashdump can trash disklabel/other partitions
Date: Mon, 25 Jun 2001 16:15:46 +1000

 Bruce Evans wrote:
 > I think you are just trashing the label becauses it is inside da1s2b, not
 > overrunning da1s2b.
 
 That was a conclusion I was starting to draw, too.
 
 > 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.
 
 Should it be there?
 
 > This bug is not seen in most configurations because the dump partition
 > usually starts at a nonzero offset.
 
 Yep.
 
 Is this configuration acceptable ('b' is a swap partition) or should
 it start at non-zero offset? Alas, I can't remember if it was
 /stand/sysinstall or /dev/luser who put it there like that.
 
 > Untested incomplete fixes (the boot block area should also be protected...):
 
 Will test 'em tomorrow and let you know. Thanks.

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 23:31:11 +1000 (EST)

 On Mon, 25 Jun 2001, Phil Homewood wrote:
 
 > Bruce Evans wrote:
 > > I think you are just trashing the label becauses it is inside da1s2b, not
 > > overrunning da1s2b.
 > 
 > That was a conclusion I was starting to draw, too.
 
 BTW, I jumped to the conclusion that it was overrunning the partition for
 you because of another report that claimed overrunning.
 
 > > 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.
 > 
 > Should it be there?
 
 Yes, they should know, since they bypass the normal block number conversion
 and bounds checking and need to understand the label (contents, not where
 it is) to do so.
 
 > > This bug is not seen in most configurations because the dump partition
 > > usually starts at a nonzero offset.
 > 
 > Is this configuration acceptable ('b' is a swap partition) or should
 > it start at non-zero offset? Alas, I can't remember if it was
 > /stand/sysinstall or /dev/luser who put it there like that.
 
 It is acceptable to me (I like corner cases to work prefectly :-), but
 is risky because it is unusual.  The same bug used to affect swapping,
 but it bit enough to get it worked around a long time ago.  The swap
 code just avoids using the first 128K or so.  It really should understand
 labels too (the label might be at a strange place, after 128K ...), or
 better, a common routine should understand all the metadata at the start
 of the device.
 
 Bruce
 

From: Phil Homewood <pdh@lineo.com>
To: Bruce Evans <bde@zeta.org.au>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/28164: [PATCH] crashdump can trash disklabel/other partitions
Date: Tue, 26 Jun 2001 11:25:37 +1000

 Bruce Evans wrote:
 > Untested incomplete fixes (the boot block area should also be protected...):
 
 This works for me, with the following additional patch, and makes much
 more sense than my effort. :-)
 
 
 --- sys/kern/kern_shutdown.c.orig       Tue Jun 26 09:50:40 2001
 +++ sys/kern/kern_shutdown.c    Tue Jun 26 09:51:04 2001
 @@ -59,6 +59,7 @@
  #include <sys/conf.h>
  #include <sys/sysproto.h>
  #include <sys/cons.h>
 +#include <sys/disklabel.h>
 
  #include <machine/pcb.h>
  #include <machine/clock.h>
 
State-Changed-From-To: open->closed 
State-Changed-By: iedowse 
State-Changed-When: Sun Dec 2 16:39:25 PST 2001 
State-Changed-Why:  

Fixed by bde in rev.1.103 of kern_shutdown.c, and MFC'd before 
4.4-RELEASE. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=28164 
>Unformatted:
