5 messages in com.xensource.lists.xen-ia64-devel[Xen-ia64-devel] Re: [XenPPC] Re: [Xe...
FromSent OnAttachments
Isaku Yamahata19 Feb 2007 00:02.patch, .patch, .patch
Hollis Blanchard26 Feb 2007 15:30 
Keir Fraser26 Feb 2007 15:38 
Hollis Blanchard26 Feb 2007 16:04 
Keir Fraser26 Feb 2007 23:50 
Subject:[Xen-ia64-devel] Re: [XenPPC] Re: [Xen-devel] [PATCH] [GNTTAB] expandable grant table
From:Keir Fraser (Keir@cl.cam.ac.uk)
Date:02/26/2007 11:50:18 PM
List:com.xensource.lists.xen-ia64-devel

On 27/2/07 00:05, "Hollis Blanchard" <holl@us.ibm.com> wrote:

I don't believe that's a concern, since updating grant_table->nr_grant_frames is the very last step in gnttab_grow_table(), and it will only grow.

If there's a memory barrier before the update of nr_grant_frames, explicitly or implied, then removing the locking from add_to_physmap is fine. Otherwise not: reading an integer is atomic, but using that as a flag to indicate presence of other state updated under the same lock is just a little bit suspect (but might be okay).

-- Keir