From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: [PATCH v1 7/8]: PVH privcmd changes Date: Fri, 5 Oct 2012 10:34:14 -0700 Message-ID: <20121005103414.22202e9a@mantra.us.oracle.com> References: <20120921122123.33489ce1@mantra.us.oracle.com> <1349270495.650.144.camel@zakaz.uk.xensource.com> <20121003153106.65237f07@mantra.us.oracle.com> <1349340642.650.227.camel@zakaz.uk.xensource.com> <20121004112048.53767720@mantra.us.oracle.com> <1349428878.20946.18.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1349428878.20946.18.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: "Xen-devel@lists.xensource.com" , Stefano Stabellini , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org On Fri, 5 Oct 2012 10:21:18 +0100 Ian Campbell wrote: > On Thu, 2012-10-04 at 19:20 +0100, Mukesh Rathor wrote: > > On Thu, 4 Oct 2012 09:50:42 +0100 > > Ian Campbell wrote: > > > > > On Wed, 2012-10-03 at 23:31 +0100, Mukesh Rathor wrote: > > > > On Wed, 3 Oct 2012 14:21:35 +0100 > > > > Ian Campbell wrote: ..... > > > > Right, that's why I had it originally checking for auto xlated > > > > and doing something different. I think that is better than to > > > > change this and change again. I'll change it back to just > > > > putting the ptr here. > > > > > > Won't that break because on the second call you will pass in the > > > freshly allocated pointer and overwrite the exiting (useful) one > > > with it? > > > > No, for xlate, I just check for NULL. I didn't think it was big > > deal to special case xlate in this case. We got so many if xlate > > cases already thru the code. It leaves the semantics easy to > > understand: NULL == avail. 1 == locked PV. PTR == Locked PVH. I'll > > add a comment this time :). > > The transition from NULL => Locked PVH still needs to be done > atomically and without clobbering any existing non-NULL value, > otherwise it doesn't actually protect against multiple mappings like > it is supposed to. > > Ian. > yes, of course :).