On Tue, 2007-10-30 at 09:16 -0400, Jaya Kumar wrote: > On 10/30/07, Peter Zijlstra <[email protected]> wrote: > > So page->index does what you want it to, identify which part of the > > framebuffer this particular page belongs to. > > Ok. I'm attempting to walk the code sequence. Here's what I think: > > - driver loads > - driver vmalloc()s its fb > - this creates the necessary pte entries well, one set thereof, the kernel mappings, which for this purpose are the least interesting. > then... > - app mmap(/dev/fb0) > - vma is created > - defio mmap adds this vma to private list (equivalent of > address_space or anon_vma) > - app touches base + pixel(128,128) = base + 16k > - page fault > - defio nopage gets called > - defio nopage does vmalloc_to_page(base+16k) this installs a user space page table entry for your page; this is the interesting one as it carries the user-dirty state. > - that finds the correct struct page corresponding to that vaddr. > page->index has not been set by anyone so far, right? > * ah... i see, you are suggesting that this is where I could set the > index since i know the offset i want it to represent. right? Not quite, you would set that right after vmallocing, just set an increasing page->index starting with 0 for the first page. Then ensure your vma->vm_pgoff is 0 (which should be the case since userspace will most likely mmap the whole thing, and if not it still gets what it expects). > - defio mkwrite get called. defio adds page to its list. schedules delayed work > - app keeps writing the page > - delayed work occurs > - 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. This will be the user-space pte installed by your nopfn handler. Not the kernel vmap pte resulting from the vmalloc() call. > - cycle repeats...
Attachment:
signature.asc
Description: This is a digitally signed message part
- Follow-Ups:
- Re: vm_ops.page_mkwrite() fails with vmalloc on 2.6.23
- From: Hugh Dickins <[email protected]>
- Re: vm_ops.page_mkwrite() fails with vmalloc on 2.6.23
- References:
- vm_ops.page_mkwrite() fails with vmalloc on 2.6.23
- From: Stefani Seibold <[email protected]>
- Re: vm_ops.page_mkwrite() fails with vmalloc on 2.6.23
- From: Andrew Morton <[email protected]>
- Re: vm_ops.page_mkwrite() fails with vmalloc on 2.6.23
- From: "Jaya Kumar" <[email protected]>
- Re: vm_ops.page_mkwrite() fails with vmalloc on 2.6.23
- From: Peter Zijlstra <[email protected]>
- Re: vm_ops.page_mkwrite() fails with vmalloc on 2.6.23
- From: "Jaya Kumar" <[email protected]>
- Re: vm_ops.page_mkwrite() fails with vmalloc on 2.6.23
- From: Peter Zijlstra <[email protected]>
- Re: vm_ops.page_mkwrite() fails with vmalloc on 2.6.23
- From: Peter Zijlstra <[email protected]>
- Re: vm_ops.page_mkwrite() fails with vmalloc on 2.6.23
- From: "Jaya Kumar" <[email protected]>
- Re: vm_ops.page_mkwrite() fails with vmalloc on 2.6.23
- From: Peter Zijlstra <[email protected]>
- Re: vm_ops.page_mkwrite() fails with vmalloc on 2.6.23
- From: "Jaya Kumar" <[email protected]>
- vm_ops.page_mkwrite() fails with vmalloc on 2.6.23
- Prev by Date: Re: eradicating out of tree modules
- Next by Date: Re: INDICATE YOUR INTEREST ...ASAP
- Previous by thread: Re: vm_ops.page_mkwrite() fails with vmalloc on 2.6.23
- Next by thread: Re: vm_ops.page_mkwrite() fails with vmalloc on 2.6.23
- Index(es):