Re: Re: A race condition in xenlinux exit_mmap

[hanzhu <hanzhu@sjtu.edu.cn>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030; format=flowed, Size: 3840 bytes --]

This patch just fail the sanity check. It should fix the bug. However, 
it didn't fix the root cause.
I'm afraid Keir will not allow to add another VM_XXX flag.

_______________________________________________________
Best Regards,
hanzhu



Ben Thomas дµÀ:
> Xin,
>
> I'm attaching a patch that we've been using since late May/early June to
> address an "Eeek" issues. Since we applied the patch, we haven't seen the
> issue.  As this was some time ago, I cannot recall if this is the same
> problem that you're seeing now. The patch wasn't submitted, as it isn't
> particularly clean. It's one of the many "some day soon" patches that we
> need to get resubmitted after a bit more work. I attach it here, not 
> because
> I believe that it is "the answer", but as a data point for you.
>
> -b
>
>
> On 8/1/06, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote:
>>
>>
>> On 1 Aug 2006, at 11:39, Li, Xin B wrote:
>>
>> >> Do you mind creating a patch to do this? I can send you more
>> >> details if you like.
>> >
>> > Sure, pls send more info on this.
>>
>>   1. Add an 'int has_foreign_mappings' to mmu_context structure
>>   2. Ensure the field is initialised in init_new_context() (e.g.,
>> memset-zero the whole structure; already done on x86/64)
>>   3. Set the field in direct_remap_pfn_range()
>>   4. Check the field in _arch_exit_mmap() to avoid calling mm_unpin().
>>
>> That's it. Just needs testing.
>>
>>   -- Keir
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>
> ------------------------------------------------------------------------
>
> # HG changeset patch
> # User lively@dlively2
> # Node ID 2d63622421e93895f9f5c99d900e80e78943b0c6
> # Parent  0b79b3c194b17dcf4d7916e33628feb321cc1e05
> Robert's workaround for the infamous Eeek! page_mapcount(page) went negative! bug.
>
> [Bug id:] 3914
>
> [Reviewed By:] Ben & Dave L
>
> diff -r 0b79b3c194b1 -r 2d63622421e9 linux-2.6-xen-sparse/drivers/xen/privcmd/privcmd.c
> --- a/linux-2.6-xen-sparse/drivers/xen/privcmd/privcmd.c	Sat Jun 10 13:23:11 2006 -0400
> +++ b/linux-2.6-xen-sparse/drivers/xen/privcmd/privcmd.c	Tue Jun 13 11:05:44 2006 -0400
> @@ -244,7 +244,7 @@ static int privcmd_mmap(struct file * fi
>  static int privcmd_mmap(struct file * file, struct vm_area_struct * vma)
>  {
>  	/* DONTCOPY is essential for Xen as copy_page_range is broken. */
> -	vma->vm_flags |= VM_RESERVED | VM_IO | VM_DONTCOPY;
> +	vma->vm_flags |= VM_RESERVED | VM_IO | VM_DONTCOPY | VM_PRIVCMD;
>  
>  	return 0;
>  }
> diff -r 0b79b3c194b1 -r 2d63622421e9 linux-2.6-xen-sparse/include/linux/mm.h
> --- a/linux-2.6-xen-sparse/include/linux/mm.h	Sat Jun 10 13:23:11 2006 -0400
> +++ b/linux-2.6-xen-sparse/include/linux/mm.h	Tue Jun 13 11:05:44 2006 -0400
> @@ -169,6 +169,7 @@ extern unsigned int kobjsize(const void 
>  #ifdef CONFIG_XEN
>  #define VM_FOREIGN	0x04000000	/* Has pages belonging to another VM */
>  #endif
> +#define VM_PRIVCMD      0x08000000      /* Pages belong to privcmd mmap */
>  
>  #ifndef VM_STACK_DEFAULT_FLAGS		/* arch can override this */
>  #define VM_STACK_DEFAULT_FLAGS VM_DATA_DEFAULT_FLAGS
> diff -r 0b79b3c194b1 -r 2d63622421e9 linux-2.6-xen-sparse/mm/memory.c
> --- a/linux-2.6-xen-sparse/mm/memory.c	Sat Jun 10 13:23:11 2006 -0400
> +++ b/linux-2.6-xen-sparse/mm/memory.c	Tue Jun 13 11:05:44 2006 -0400
> @@ -409,6 +409,10 @@ struct page *vm_normal_page(struct vm_ar
>  			print_bad_pte(vma, pte, addr);
>  		return NULL;
>  	}
> +
> +        /* This vma points to foreign pages */
> +        if (vma->vm_flags & VM_PRIVCMD)
> +            return NULL;
>  
>  	/*
>  	 * NOTE! We still have PageReserved() pages in the page 
>