Kevin Pedretti wrote: > > 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. Nope. > 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? See kernel/timer.c:count_active_tasks(). It does read_lock(&task_list_lock) to pin everything down while it walks the task list in an interrupt. And you're in luck - tasklist_lock is exported to modules. > 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). That sounds sane. Pin the user pages, set up a kernel virtual mapping of them. You can't rely on userspace having performed the mlock of course; you'll need to pin the pages in-kernel. Probably you can just use map_user_kiobuf(). > 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). > I guess that if you've pinned the pages, then you're safe even if the task exits - the pages won't be going away. But your interrupt will need to deal with the kiovec, not the process mm. This could end up meaning that your final page_cache_release() happens in interrupt context. We may have a problem with that if the page is still on the global LRU. See the thread starting at http://www.uwsg.iu.edu/hypermail/linux/kernel/0202.0/1157.html - -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
