[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <45a44e480710300616p34b0a159m87de78d0a4d43028@mail.gmail.com>
Date: Tue, 30 Oct 2007 09:16:40 -0400
From: "Jaya Kumar" <jayakumar.lkml@...il.com>
To: "Peter Zijlstra" <a.p.zijlstra@...llo.nl>
Cc: "Andrew Morton" <akpm@...ux-foundation.org>, stefani@...bold.net,
linux-kernel@...r.kernel.org,
"David Howells" <dhowells@...hat.com>, linux-mm@...ck.org,
"Hugh Dickins" <hugh@...itas.com>
Subject: Re: vm_ops.page_mkwrite() fails with vmalloc on 2.6.23
On 10/30/07, Peter Zijlstra <a.p.zijlstra@...llo.nl> 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
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)
- 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?
- 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) }
- cycle repeats...
Thanks,
jaya
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists