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.
6bfb820292