Re: [x86_64] 2.6.14-git13 mplayer fails with "v4l2: ioctl queue buffer failed: Bad address" (2 Nov 2005, 11 Nov 2005)

[Junichi Uekawa]

Hi,

> This EFAULT rejection is due to change in  get_user_pages()  function
> in mm/memory.c  file of  2.6.14-git2
> 
> 
> @@ -945,8 +947,8 @@ int get_user_pages(struct task_struct *t
>                         continue;
>                 }
>  
> -               if (!vma || (vma->vm_flags & VM_IO)
> -                               || !(flags & vma->vm_flags))
> +               if (!vma || (vma->vm_flags & (VM_IO | VM_RESERVED))
> +                               || !(vm_flags & vma->vm_flags))
>                         return i ? : -EFAULT;
>  
>                 if (is_vm_hugetlb_page(vma)) {
> 
> 
> I don't know how to use git tools to see, whose patch actually
> did this particular change.

To quote:
>    MAP_PRIVATE, PROT_WRITE of VM_RESERVED regions is tentatively being
>    deprecated.  We never completely handled it correctly anyway, and is be
>    reintroduced in future if required (Hugh has a proof of concept).





diff-tree b5810039a54e5babf428e9a1e89fc1940fabff11 (from f9c98d0287de42221c62448Author: Nick Piggin <nickpiggin@xxxxxxxxxxxx>
Date:   Sat Oct 29 18:16:12 2005 -0700

    [PATCH] core remove PageReserved

    Remove PageReserved() calls from core code by tightening VM_RESERVED
    handling in mm/ to cover PageReserved functionality.

    PageReserved special casing is removed from get_page and put_page.

    All setting and clearing of PageReserved is retained, and it is now flagged
    in the page_alloc checks to help ensure we don't introduce any refcount
    based freeing of Reserved pages.

    MAP_PRIVATE, PROT_WRITE of VM_RESERVED regions is tentatively being
    deprecated.  We never completely handled it correctly anyway, and is be
    reintroduced in future if required (Hugh has a proof of concept).

    Once PageReserved() calls are removed from kernel/power/swsusp.c, and all
    arch/ and driver code, the Set and Clear calls, and the PG_reserved bit can
    be trivially removed.

    Last real user of PageReserved is swsusp, which uses PageReserved to
    determine whether a struct page points to valid memory or not.  This still
    needs to be addressed (a generic page_is_ram() should work).

    A last caveat: the ZERO_PAGE is now refcounted and managed with rmap (and
    thus mapcounted and count towards shared rss).  These writes to the struct
    page could cause excessive cacheline bouncing on big systems.  There are a
    number of ways this could be addressed if it is an issue.

    Signed-off-by: Nick Piggin <npiggin@xxxxxxx>

    Refcount bug fix for filemap_xip.c

    Signed-off-by: Carsten Otte <cotte@xxxxxxxxxx>
    Signed-off-by: Andrew Morton <akpm@xxxxxxxx>
    Signed-off-by: Linus Torvalds <torvalds@xxxxxxxx>



I think the relevant changes (snipped out) are:

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 0c64484..da42093 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -157,7 +157,7 @@ extern unsigned int kobjsize(const void

 #define VM_DONTCOPY    0x00020000      /* Do not copy this vma on fork */
 #define VM_DONTEXPAND  0x00040000      /* Cannot expand with mremap() */
-#define VM_RESERVED    0x00080000      /* Don't unmap it from swap_out */
+#define VM_RESERVED    0x00080000      /* Pages managed in a special way */
 #define VM_ACCOUNT     0x00100000      /* Is a VM accounted object */
 #define VM_HUGETLB     0x00400000      /* Huge TLB Page VM */
 #define VM_NONLINEAR   0x00800000      /* Is non-linear (remap_file_pages) */

diff --git a/mm/memory.c b/mm/memory.c
index da642b5..e83f944 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -967,7 +992,7 @@ int get_user_pages(struct task_struct *t
                        continue;
                }

-               if (!vma || (vma->vm_flags & VM_IO)
+               if (!vma || (vma->vm_flags & (VM_IO | VM_RESERVED))
                                || !(flags & vma->vm_flags))
                        return i ? : -EFAULT;



regards,
	junichi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/