Eugene, destroy_context(..) can be called from other place outside of
the scheduler and switch_mm(...). See mmdrop(...) for example.
In many of those cases, the task will run with preemption enable.
Guillaume.
Eugene Surovegin wrote:
>On Tue, Jul 12, 2005 at 10:23:51AM -0400, Guillaume Autran wrote:
>
>
>>Fix for a race condition when a task gets preempted by another task
>>while executing the destroy_context(...) in a FEW_CONTEXTS environment.
>>mm->context == NO_CONTEXT but the context_map may indicate all contexts
>>are in use.
>>The solution to this problem is to disable kernel preemption while
>>destroying a MMU context.
>>
>>Signed-off-by: Guillaume Autran <gautran at mrv.com>
>>
>>---
>>
>>diff -Nru a/include/asm-ppc/mmu_context.h b/include/asm-ppc/mmu_context.h
>>--- a/include/asm-ppc/mmu_context.h 2005-06-17 15:48:29.000000000 -0400
>>+++ b/include/asm-ppc/mmu_context.h 2005-07-05 08:58:46.000000000 -0400
>>@@ -149,6 +149,7 @@
>>*/
>>static inline void destroy_context(struct mm_struct *mm)
>>{
>>+ preempt_disable();
>> if (mm->context != NO_CONTEXT) {
>> clear_bit(mm->context, context_map);
>> mm->context = NO_CONTEXT;
>>@@ -156,6 +157,7 @@
>> atomic_inc(&nr_free_contexts);
>>#endif
>> }
>>+ preempt_enable();
>>}
>>
>>static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next,
>>
>>
>>
>
>Could you explain, why this patch is needed?
>
>AFAIK, destroy_context() is only called from switch_mm(), which in
>turn is called from schedule() with preemption already disabled. If
>not, IMHO we have bigger problems, and "fixing" destroy_context() will
>only hide such problems.
>
>
>
--
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
E-mail: gautran at mrv.com
=======================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050712/2e0fa13c/attachment.htm
