From owner-cvs-all Wed Jan 26 21:11:35 2000 Delivered-To: cvs-all@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 4FB2B154A7; Wed, 26 Jan 2000 21:11:33 -0800 (PST) (envelope-from bde@FreeBSD.org) Received: (from bde@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id VAA02544; Wed, 26 Jan 2000 21:11:32 -0800 (PST) (envelope-from bde@FreeBSD.org) Message-Id: <200001270511.VAA02544@freefall.freebsd.org> From: Bruce Evans Date: Wed, 26 Jan 2000 21:11:31 -0800 (PST) To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/kern subr_diskmbr.c Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk bde 2000/01/26 21:11:31 PST Modified files: sys/kern subr_diskmbr.c Log: Quick fix for stack overflow when there are more than about 25 slices. Using recursion to traverse the recursive data structure for extended partitions was never good, but when slice support was implemented in 1995, the recursion worked for the default maximum number of slices (32), and standard fdisk utilities didn't support creating more than the default number. Even then, corrupt extended partitions could cause endless recursion, because we attempt to check all slices, even ones which we don't turn into devices. The recursion has succumbed to creeping features. The stack requirements for each level had grown to 204 bytes on i386's. Most of the growth was caused by adding a 64-byte copy of the DOSpartition table to each frame. The kernel stack size has shrunk to about 5K on i386's. Most of the shrinkage was caused by the growth of `struct sigacts' by 2388 bytes to support 128 signals. Linux fdisk (a 1997 version at least) can now create 60 slices (4 standard ones, 56 for logical drives within extended partitions, and it seems to be leaving room to map the 4 BSD partitions on my test drive), and Linux (2.2.29 and 2.3.35 at least) now reports all these slices at boot time. The fix limits the recursion to 16 levels (4 + 16 slices) and recovers 32 bytes per level caused by gcc pessimizing for space. Switching to a static buffer doesn't cause any problems due to recursion, since the buffer is not passed down. Using a static buffer is wrong in general because it requires the giant lock to protect it. However, this problem is small compared with using a static buffer for dsname(). We sometimes neglect to copy the result of dsname() before sleeping. Also fixed slice names when we find more than MAX_SLICES (32) slices. The number of the last slice found was not passed passed recursively. The limit on the recursion now prevents finding more than 32 slices with a standard extended partition data structure anyway. Revision Changes Path 1.44 +28 -11 src/sys/kern/subr_diskmbr.c To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message