From owner-cvs-all Sat Oct 5 22:15:34 2002 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCED837B401; Sat, 5 Oct 2002 22:15:32 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 758F54416C; Sat, 5 Oct 2002 22:11:53 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id PAA11802; Sun, 6 Oct 2002 15:11:38 +1000 Date: Sun, 6 Oct 2002 15:21:29 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Brian Somers Cc: brian@FreeBSD.org, , Subject: Re: cvs commit: src/sys/kern subr_disk.c In-Reply-To: <20021006014026.63604067.brian@Awfulhak.org> Message-ID: <20021006150606.A15369-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 6 Oct 2002, Brian Somers wrote: > On Sun, 6 Oct 2002 00:15:37 +1000 (EST), Bruce Evans wrote: > > This seems to only unbreak the case where the partition size is 0. At > > least the i386 dumpsys() has no bounds checking at the partition level. > > It clobbers sectors outside of the partition starting at the non-random > > offset dumplo given by: > > > > dumplo = di->mediaoffset + di->mediasize - Maxmem * (off_t)PAGE_SIZE; > > dumplo -= sizeof kdh * 2; > > > > except in the following cases: > > ... > > I'm not sure what ``space for metadata'' is for. The attached patch seems to > get the answer right here on i386, although I can't vouch for ia64 or sparc64 > working correctly (their dumpsys() seems different). It is machine-dependent. RELENG_4 leaves enough space for the label and all sectors before it. Since the i386 MBR is before the label, it gets protected too, even in the dangerously dedicated case where the MBR is on the same slice as the dump partition (and the dump partition is at offset 0). The swapper leaves a fairly arbitrary and much larger than normally necessary space for metadata (64K IIRC). > Do you think I should commit this ? The check is too machine-dependent to put in subr_disk.c. Apart from labelling differences: - different arches might want to right different headers - compression might be implemented, and the size is not known yet - some arches (e.g., ia64) write sparse data, so Maxmem gives a wrong size. Bounds checking is similarly nonexistent on ia64's, but this is easy to fix at the point where dumplo is calculated. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message