RE: do_exit() and lock_kernel() semantics

[Ashok Raj]

1. your driver must have a way to syncup with intr routine accesssing this
buffer. The way we do this is by synching access to this buffer and making
sure your file close cleans up this, so intr routine does not touch this
buffer if process is exited. (assuming you provide access via file handles,
and handle the cleanup as file close)

2. you cannot do the user virtual to kernel address during an intr call. You
must do this and cache the list of page numbers. (then convert the page
number to kva before doing the copy). You must also be aware that if the
buffer crosses page boundaries (i.e true virtual addr spanning pages, you
might need to do this copy multiple times.) since there is no function in
linux kernel to obtain a kva for a uva.

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Kevin Pedretti
Sent: Monday, March 25, 2002 11:25 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: do_exit() and lock_kernel() semantics

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