do_exit() and lock_kernel() semantics

[Kevin Pedretti <ktpedre@sandia.gov>]

Hello,
    do_exit() does a lock_kernel() before it destroys the dying 
processes mm context (sets task_struct->mm to NULL in 2.4 and &init_mm 
in 2.2).  Does lock_kernel() somehow disable interrupts?  It doesn't 
look like it does.  


Is there anyway from an interrupt context to check if a process is still 
alive (not exiting) and prevent it from exiting until the ISR is over? 
 I guess if lock_kernel disables interrupts globally and waits for 
inprogress interrupts to complete, then this isn't a problem.


More detail:
The reason I ask is that I'm working on/modifying a set of modules that 
accesses user space from interrupt context.  I know this is not a good 
thing to do generally, but for performance reasons the original author 
wanted to copy directly into a mlocked user space buffer from a network 
receive interrupt.  Since the buffer is mlocked, it is always guaranteed 
to be there and no page faults will happen (right??? I'm new at this). 
 Thus, for each receive we have to convert the virt address of the 
user-land receive buffer to a physical address (in the kernel region) 
before doing the memcpy (copy_to_user doesn't work from interrupt 
context).   This all seems to work fine in practice.  However, it seems 
to me that there is a race that can happen if a process is in the middle 
of dying and a receive interrupt happens.  task->mm can be set to 
NULL/init_mm out from under me while doing a receive (e.g. on another cpu).


Thanks for any help.

Kevin