WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Fwd: Re: struct page field arrangement

To: Jan Beulich <jbeulich@xxxxxxxxxx>, Keir Fraser <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Fwd: Re: struct page field arrangement
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Fri, 16 Mar 2007 12:11:49 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 16 Mar 2007 05:11:02 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <45FA948B.76E4.0078.0@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcdnxEYPhFpETNO3EduhtwAX8io7RQ==
Thread-topic: [Xen-devel] Fwd: Re: struct page field arrangement
User-agent: Microsoft-Entourage/11.2.5.060620
On 16/3/07 11:58, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

>> Since the pin/unpin walking only cares about pgd/pud/pmd entries,
>> synchronization
>> is guaranteed through mm->page_table_lock. The pte lock is used only for leaf
>> entries, which are of no concern to (un)pinning.
> 
> I'm afraid I have to correct myself. Stress testing has shown severe
> problems, and after a few hours of staring at this I'm almost certain there
> is a race condition here: While no new pte-s can ever appear, the logic in
> mm/vmscan.c may try to modify pte-s in an mm currently being unpinned
> (at least through ptep_clear_flush_young() called from
> page_referenced_one() in mm/rmap.c). If this happens when
> xen_pgd_unpin() has already passed the respective pte page, but
> mm_walk() hasn't reached the page, yet, the update will fail (if done
> directly, ptwr will no pick this up, and if done through a hypercall, the
> call would fail, likely producing a BUG()).

What kind of stress test did you run? I was expecting that unpin would be
okay because we only call mm_unpin() from _arch_exit_mmap() if the mm_count
is 1 (which I believe means the mm is not active in any task).

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel