[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <45a44e480710291822w5864b3beofcf432930d3e68d3@mail.gmail.com>
Date: Mon, 29 Oct 2007 21:22:26 -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/29/07, Peter Zijlstra <a.p.zijlstra@...llo.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.
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