Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site opus.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!hao!cires!nbires!opus!jmoore
From: jmoore@opus.UUCP (Jim Moore)
Newsgroups: net.unix-wizards
Subject: spl5() call in kern_exit.c
Message-ID: <785@opus.UUCP>
Date: Sun, 9-Sep-84 20:22:01 EDT
Article-I.D.: opus.785
Posted: Sun Sep  9 20:22:01 1984
Date-Received: Sun, 16-Sep-84 09:11:42 EDT
Distribution: net
Organization: NBI, Boulder
Lines: 34

Sorry if this request came across before, but our net feed was down
and I do not know if this message got out.

I am trying to cut down the amount of time that our 4.2 kernel runs
at high interrupt priority and I came across the following code in
kern_exit function exit():

	vrelpt(u.u_procp);
	vrelu(u.u_procp, 0);
	(void) spl5();		/* hack for mem alloc race XXX */

And similar code in vm_swap.c function swapout():

	(void) spl6();		/* hack memory interlock XXX */
	vrelu(p, 1);
	.
	.
	vrelpt(p);

I would like to know the reason for the interrupt lockout. In both
situations it is possible that the current process is running on
a kernel stack whose pages have been put on the free list. Does this
mean that someone is allocating memory in an interrupt routine?
A routine in the callout list? This would imply that the code in
kern_exit.c is wrong because the spl5() is called too late. Why is
one spl5() and the other spl6()? Are these pieces of code even related?

Oh, so many questions and if I receive answers I'll certainly forward
them to interested parties or summarize on request.

Many thanks,
Jim Moore, NBI, Boulder Colorado
[ucbvax|hao|amd]!nbires!jmoore