From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Fwd: Re: struct page field arrangement Date: Fri, 16 Mar 2007 15:15:35 +0000 Message-ID: <45FAC2A7.76E4.0078.0@novell.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> Keir Fraser 16.03.07 15:30 >>> >On 16/3/07 14:13, "Keir Fraser" wrote: > >> Either we are in stop_machine context, or we have offlined all other CPUs >> via cpu hotplug. In the absence of involuntary preemption it's therefore >> safe to proceed without locking. But probably inadvisable (we'd like to >> support full CONFIG_PREEMPT sometime in the future)... I think the 386 code >> should be changed to match x86/64. > >Actually it's not so easy. We walk the pgd_list and so do not have the mm >associated with the pgd. And in some cases there may not be an mm, if we >walk the list after a pgd is allocated but before it is attached to an mm. 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. >So I think we should simply disable preemption in the i386 case. Which is >done easily by simply taking the pgd_lock (which it would be polite to do >anyway, since we're walking the pgd_list). With preemption disabled we're >definitely safe because pinning is non-blocking and all other CPUs are >safely spinning in stop_machine or have been offlined. And what about the pgd_test_and_unpin() case? >Actually preemption is already disabled by the caller (for a different >reason) but it's not nice to rely on that. Jan