From: Hugh Dickins <hugh@veritas.com>
To: Stefani Seibold <stefani@seibold.net>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
Jaya Kumar <jayakumar.lkml@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, David Howells <dhowells@redhat.com>,
linux-mm@kvack.org
Subject: Re: vm_ops.page_mkwrite() fails with vmalloc on 2.6.23
Date: Tue, 30 Oct 2007 12:39:20 +0000 (GMT) [thread overview]
Message-ID: <Pine.LNX.4.64.0710301232220.9601@blonde.wat.veritas.com> (raw)
In-Reply-To: <1193741356.13775.2.camel@matrix>
On Tue, 30 Oct 2007, Stefani Seibold wrote:
>
> the question is how can i get all pte's from a vmalloc'ed memory. Due to
> the zeroed mapping pointer i dont see how to do this?
The mapping pointer is zeroed because you've done nothing to set it.
Below is how I answered you a week ago. But this is new territory
(extending page_mkclean to work on more than just pagecache pages),
I'm still unsure what would be the safest way to do it.
On Mon, 22 Oct 2007, Stefani Seibold wrote:
>
> i have a problem with vmalloc() and vm_ops.page_mkwrite().
>
> ReadOnly access works, but on a write access the VM will
> endless invoke the vm_ops.page_mkwrite() handler.
>
> I tracked down the problem to the
> struct page.mapping pointer,
> which is NULL.
>
> The problem original occurs with the fb_defio driver (driver/video/fb_defio.c).
> This driver use the vm_ops.page_mkwrite() handler for tracking the modified pages,
> which will be in an extra thread handled, to perform the IO and clean and
> write protect all pages with page_clean().
Interesting. You need to ask Jaya (CC'ed) since he's the one
who put that code into fb_defio.c, exported page_mkclean, and
should have tested it.
>
> I am not sure if the is a feature of the new rmap code or a bug.
page_mkclean was written in the belief that it was being used on
pagecache pages. I'm not sure how deeply engrained that belief is.
If it can easily and safely be used on something else, that may be
nice: though there's a danger we'll keep breaking and re-breaking
it if there's only one driver using it in an unusual way. CC'ed
Peter since he's the one who most needs to be aware of this.
>
> Is there an way to get a similar functionality? Currently, i have no
> idea
> how to get the ptep from a page alloced with vmalloc().
A pagecache page would have page->mapping initialized to point to
the struct address_space of the vma, and page->index to the offset
(in PAGE_SIZE units): see mm/filemap.c:add_to_page_cache. Without
page->mapping set, page_mkclean_file won't be able to find the vmas
in which the page might appear; and without page->index set, it
won't be able to find where the page should be in those vmas.
If such a driver does not put its pages into the page cache (the
safer course? I'm unsure), then it needs to set page->mapping and
page->index appropriately (and reset page->mapping to NULL before
freeing).
Hugh
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2007-10-30 12:39 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1193064057.16541.1.camel@matrix>
2007-10-29 7:40 ` Andrew Morton
2007-10-29 8:17 ` Jaya Kumar
2007-10-29 10:11 ` Peter Zijlstra
2007-10-29 12:35 ` Peter Zijlstra
2007-10-29 14:28 ` Nick Piggin
2007-10-29 17:01 ` Peter Zijlstra
2007-10-29 17:51 ` Jaya Kumar
2007-10-29 18:17 ` Peter Zijlstra
2007-10-29 22:16 ` Peter Zijlstra
2007-10-30 1:22 ` Jaya Kumar
2007-10-30 9:56 ` Peter Zijlstra
2007-10-30 10:49 ` Stefani Seibold
2007-10-30 12:39 ` Hugh Dickins [this message]
2007-10-30 13:12 ` Peter Zijlstra
2007-10-30 13:16 ` Jaya Kumar
2007-10-30 13:25 ` Peter Zijlstra
2007-10-30 15:47 ` Hugh Dickins
2007-10-30 15:51 ` Peter Zijlstra
2007-11-01 8:02 ` Jaya Kumar
2007-10-22 14:45 Stefani Seibold
2007-10-22 16:37 ` Hugh Dickins
2007-10-22 17:03 ` Jaya Kumar
2007-10-22 17:17 ` Peter Zijlstra
2007-10-22 17:20 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.0710301232220.9601@blonde.wat.veritas.com \
--to=hugh@veritas.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=dhowells@redhat.com \
--cc=jayakumar.lkml@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=stefani@seibold.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox