[lkml]   [2007]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: vm_ops.page_mkwrite() fails with vmalloc on 2.6.23
    On Mon, 2007-10-29 at 21:22 -0400, Jaya Kumar wrote:
    > On 10/29/07, Peter Zijlstra <> wrote:
    > >
    > > [ also, remap_vmalloc_range() suffers similar issues, only file and anon
    > > have proper rmap ]
    > >
    > > I'm not sure we want full rmap for remap_pfn/vmalloc_range, but perhaps
    > > we could assist drivers in maintaining and using vma lists.
    > >
    > > I think page_mkclean_one() would work if you'd manually set page->index
    > > and iterate the vmas yourself. Although atm I'm not sure of anything so
    > > don't pin me on it.
    > :-) If it's anybody's fault, it's mine for not testing properly. My bad.
    > In the case of defio, I think it's no trouble to build a list of vmas
    > at mmap time and then to iterate through them when it's ready for
    > mkclean time as you suggested. I don't fully understand page->index
    > yet. I had thought it was only used by swap cache or file map.
    > On an unrelated note, I was looking for somewhere to stuff a 16 bit
    > offset (so that I have a cheap way to know which struct page
    > corresponds to which framebuffer block or offset) for another driver.
    > I had thought page->index was it but I think I am wrong now.

    Yeah, page->index is used along with vma->vmpgoff and vma->vm_start to
    determine the address of the page in the given vma:

    address = vma->vm_start + ((page->index - vma->vm_pgoff) << PAGE_SHIFT);

    and from that address the pte can be found by walking the vma->vm_mm
    page tables.

    So page->index does what you want it to, identify which part of the
    framebuffer this particular page belongs to.
    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2007-10-30 10:59    [W:0.019 / U:7.944 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site