Removing kernel thread stack swapping

[Brooks Davis]

On Thu, Mar 03, 2005 at 09:54:07AM -0500, John Baldwin wrote:
> On Thursday 03 March 2005 02:42 am, David Schultz wrote:
> > Any objections to the idea of removing the feature of swapping out
> > kernel stacks?  Unlike disabling UAREA swapping, this has the
> > small downside that it wastes 16K (give or take a power of 2) of
> > wired memory per kernel thread that we would otherwise have
> > swapped out.  However, this disadvantage is probably negligible by
> > today's standards, and there are several advantages:
> >
> > 1. David Xu found that some kernel code stores externally-accessible
> >    data structures on the stack, then goes to sleep and allows the
> >    stack to become swappable.  This can result in a kernel panic.
> 
> He found one instance.
> 
> > 2. We don't know how many instances of the above problem there are.
> >    Selectively disabling swapping for the right threads at the
> >    right times would decrease maintainability.
> 
> Probably 1.  Note that since at least FreeBSD 1.0 programmers have had to 
> realize that the stack can be swapped out.  The signal code in pre-5.x stores 
> part of the signal state in struct proc directly in order to support swapped 
> out stacks.  In 5.x we just malloc the whole signal state directly since we 
> killed the u-area.  sigwait() has a bug that should be fixed, let's not 
> engage in overkill and throw the baby out with the bath water.  In general we 
> need to discourage use of stack variables anyway because when people use 
> stack space rather than malloc() space the failure case for running out is 
> much worse, i.e. kernel panic when you overflow your stack (even though KVM 
> may be available) vs. waiting until some memory is available or returning 
> NULL.
> 
> Hence, don't kill this whole feature just because someone is too lazy
> to fix a bug.

It would be very useful and informative if someone were to write a
high level description of the ways in which the kernel is not a POSIX C
programming environment.  In addition to providing somewhere to point
people who wonder why -lbigcomplicatedlibrary doesn't work with their
kernel source, such a list would force us to enumerate those differences
and make sure they are based on design decisions that make sense.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20050303/0d8ad5f1/attachment.bin