Re: [uml-devel] iptables-restore randomly crashes under UML

[Henrik Nordstrom <hno@marasystems.com>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2307 bytes --]

On Tue, 2 Dec 2003, Henrik Nordstrom wrote:

> On Mon, 1 Dec 2003, Henrik Nordstrom wrote:
> 
> > I have got so far that it looks like the pte is not modified making me 
> > suspect that there is a old page mapping around initially maybe not 
> > maching the pte after the call to vmalloc().
> 
> This has now been confirmed.
> 
> Now remains to figure out why the mapping of the old page is still 
> around and why the tlb mappings has not been synched.

This too has now been identified, but I am not sure what is the best way 
to fix this.

vfree() calls flush_tlb_all(), but as this does not update the vm_seq
number old the mapping is still there unless there is another page fault
before the page is referenced again. Because of this there is a race if
vmalloc() returns the same area that was last vmfree():d causing that area
to temporarily refer to the old physical location until the next kernel
page fault and quickly resulting in very odd results..

What I wonder is if this can be fixed without dropping the vm_seq
optimization of tt kernel virtual memory updates. But from looking at the
skas implementation I suppose dropping the vm_seq optimization is the
correct way.. (skas does not have this optimization and should thus be
safe from the issue)

I have now removed this vm_seq optimization from my kernel sources and
have verified that the iptables-restore problem is no where to be seen 
with this vm_seq optimization disabled. [silly patch attached just to 
illustrate the problem area]

What was the design thought behind the vm_seq optimization? I understand
the principle, but not the conditions when it can be safely deduced that
the init_mm has not been updated since the last flush_kernel_vm_range().

I still think the kernel vm pte mappings should be mirrored into the
current process and flush_kernel_vm_range() changed to do incremental
remaps where the kernel vm pte mappings of init_mm differs from the
current process. This applies to both tt and skas mode. With the kernel vm
area being very limited in size such optimization should not be very hard
or costly to accomplish and will by far outperform the mm_seq optimization
of tt.. but my understanding of this is still a little limited so it might
well be the case that this is not worth bothering with.

Regards
Henrik

[-- Attachment #2: tlb_flush_all() workaround for TT mode --]
[-- Type: TEXT/PLAIN, Size: 674 bytes --]

Index: arch/um/kernel/tt/tlb.c
===================================================================
RCS file: /cvsroot/user-mode-linux/linux/arch/um/kernel/tt/tlb.c,v
retrieving revision 1.4
diff -u -w -p -r1.4 tlb.c
--- arch/um/kernel/tt/tlb.c	20 Dec 2002 23:54:49 -0000	1.4
+++ arch/um/kernel/tt/tlb.c	2 Dec 2003 00:51:42 -0000
@@ -197,7 +197,9 @@ void flush_tlb_mm_tt(struct mm_struct *m
 	fix_range(mm, 0, STACK_TOP, 0);
 
 	seq = atomic_read(&vmchange_seq);
+#if THIS_OPTIMIZATION_DOES_NOT_WORK_PROPERLY
 	if(current->thread.mode.tt.vm_seq == seq) return;
+#endif
 	current->thread.mode.tt.vm_seq = seq;
 	flush_kernel_vm_range(start_vm, end_vm, 0);
 }