From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Fwd: Re: struct page field arrangement Date: Fri, 16 Mar 2007 15:30:05 +0000 Message-ID: References: <45FAC2A7.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <45FAC2A7.76E4.0078.0@novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich , Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 16/3/07 15:15, "Jan Beulich" wrote: > But without being attached to an mm, the user portion of the pgd should > be blank? I really can't follow why i386 requires so much more special > handling here than x86-64. PAE allocates the pmd's early (in pgd_alloc() in fact). So any pgd_alloc()ed pgd must be captured by mm_pin_all(). > And what about the pgd_test_and_unpin() case? It's only called from pgd_alloc, pgd_free, pgd_dtor. I'm not sure it's needed in all those places, but it's needed in some of them to deal with the case that _arch_exit_mmap() didn't unpin the pgd, because a PAE pgd does not lose its pmd's until pgd_free(). In none of those cases is there a concurrency problem: there's no mm associated with the pgd and hence no concurrency issue. I just checked in a patch to clarify some of this, particularly around mm_pin_all, as c/s 14408. Feel free to submit more clarification patches -- I suspect a few more comments around these functions would help avoid confusion! -- Keir