From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1756169AbXJ3Psh@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1756169AbXJ3Psh (ORCPT <rfc822;w@1wt.eu>);
	Tue, 30 Oct 2007 11:48:37 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753892AbXJ3Psa
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Tue, 30 Oct 2007 11:48:30 -0400
Received: from extu-mxob-2.symantec.com ([216.10.194.135]:34653 "EHLO
	extu-mxob-2.symantec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753168AbXJ3Ps3 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 30 Oct 2007 11:48:29 -0400
Date: Tue, 30 Oct 2007 15:47:40 +0000 (GMT)
From: Hugh Dickins <hugh@veritas.com>
X-X-Sender: hugh@blonde.wat.veritas.com
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
cc: Jaya Kumar <jayakumar.lkml@gmail.com>,
       Andrew Morton <akpm@linux-foundation.org>, stefani@seibold.net,
       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
In-Reply-To: <1193750751.27652.86.camel@twins>
Message-ID: <Pine.LNX.4.64.0710301535270.9322@blonde.wat.veritas.com>
References: <1193064057.16541.1.camel@matrix>  <20071029004002.60c7182a.akpm@linux-foundation.org>
  <45a44e480710290117u492dbe82ra6344baf8bb1e370@mail.gmail.com> 
 <1193677302.27652.56.camel@twins>  <45a44e480710291051s7ffbb582x64ea9524c197b48a@mail.gmail.com>
  <1193681839.27652.60.camel@twins> <1193696211.5644.100.camel@lappy> 
 <45a44e480710291822w5864b3beofcf432930d3e68d3@mail.gmail.com> 
 <1193738177.27652.69.camel@twins>  <45a44e480710300616p34b0a159m87de78d0a4d43028@mail.gmail.com>
 <1193750751.27652.86.camel@twins>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

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?

Hugh