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 16:51:02 +0100 |
| |
On Tue, 2007-10-30 at 15:47 +0000, Hugh Dickins wrote: > On Tue, 30 Oct 2007, Peter Zijlstra wrote: > > On Tue, 2007-10-30 at 09:16 -0400, Jaya Kumar wrote: > .... > > > - defio mmap adds this vma to private list (equivalent of > > > address_space or anon_vma) > .... > > > - foreach vma { foreach page { page_mkclean_one(page, vma) } > > > > Yeah, page_mkclean_one(page, vma) will use vma_address() to obtain an > > user-space address for the page in this vma using page->index and the > > formula from the last email, this address is then used to walk the page > > tables and obtain a pte. > > I don't understand why you suggested an anon_vma, nor why Jaya is > suggesting a private list. All vmas mapping /dev/fb0 will be kept > in the prio_tree rooted in its struct address_space (__vma_link_file > in mm/mmap.c). And page_mkclean gets page_mkclean_file to walk that > very tree. The missing part is just the setting of page->mapping to > point to that struct address_space (and clearing it before finally > freeing the pages), and the setting of page->index as you described. > Isn't it?
Hmm, there is a thought. I had not considered that mapping a chardev would have that effect.
I'd have to have a look at the actual code, but yeah, that might very well work out. How silly of me.
Thanks! [unhandled content-type:application/pgp-signature] | |