Messages in this thread |  | | | Subject | Re: vm_ops.page_mkwrite() fails with vmalloc on 2.6.23 | | From | Peter Zijlstra <> | | Date | Tue, 30 Oct 2007 10:56:17 +0100 |
| |
On Mon, 2007-10-29 at 21:22 -0400, Jaya Kumar wrote: > On 10/29/07, Peter Zijlstra <a.p.zijlstra@chello.nl> 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] |  |