Subject: Re: curproc removal (NFS, ...)
To: Jonathan Stone <>
From: Jason Thorpe <>
List: tech-kern
Date: 05/25/2004 16:31:25
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

On May 25, 2004, at 4:25 PM, Jonathan Stone wrote:

> Well, .. probably. Maybe. (in a fine-grained SMP kernel its less clear
> than a uP kernel, or a big-lock kernel like we have now.)  It might be
> fun to do a retrospective in a year or so.

Plenty of MP-safe kernels have curproc or a curproc analogue.

> But its more than a little off-point when we're trying to pin down
> where it is (and isn't) safe to call sosend() and soreceive() from
> (say) softint context.

That is never safe anyway, for various reasons.  Not the least of which:

(1) They may block.

(2) When they have fine-grained locking there, they may block 
(lockmgr() locks sleep).  It's not really appropriate for all locking 
to be done with simplelocks; only those things that need to be locked 
from an interrupt context.

I have been feeling generally uneasy with this whole notion of 
"kcont-based NFS server", precisely because I don't think many people 
have their head wrapped around what can and can't be done in interrupt 
context, nor do they necessarily understand the broader consequences of 
changing code TO work in an interrupt context.

         -- Jason R. Thorpe <>

content-type: application/pgp-signature; x-mac-type=70674453;
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

Version: GnuPG v1.2.3 (Darwin)