Re: vm_ops.page_mkwrite() fails with vmalloc on 2.6.23

[Peter Zijlstra <a.p.zijlstra@chello.nl>]

[-- Attachment #1: Type: text/plain, Size: 1334 bytes --]

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!

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]