> atomic_inc(&best->mm_count);
> ret = swap_out_mm(best, gfp_mask);
> mmdrop(best);
>
>seems to be not safe since the place where we increase the mm_count has
Continuing thinking about it, the above seems safe for a subtle reason:
because we can't set tsk->mm to zero without holding the big kernel lock.
Anyway it wasn't that obvious since the obvious thing is to increase
the count and drop some kind of SMP locking ;).
About the vmas, the find_vma in swap_out_mm() can be parallel to
avl_remove in do_munmap for example. That seems really possible to me. If
I am wrong I'll appreciate corrections of course.
I have an Oops in flush_tlb_mm() called from try_to_swap_out(). The Oops
happens while dereferncing vma->vm_mm because vma->vm_mm is zero.
The first problem I noticed was the not SMP safe vma_cpu_mask handling in
the flushing routines (and with my tlb-flush patch the SMP problems goes
away but I believe it's not the right fix now that I see the point for the
current code ;).
With my SMP-flush patch the Oops looked harder to reproduce, anyway I
believe the reason of the Oops is that the vma goes away and gets zeroed
under the swapout path.
Hints?
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/