From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: [PATCH v1 7/8]: PVH privcmd changes Date: Thu, 4 Oct 2012 11:20:48 -0700 Message-ID: <20121004112048.53767720@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1349340642.650.227.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 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: > > > > > On Fri, 2012-09-21 at 20:21 +0100, Mukesh Rathor wrote: > > > > +static int pvh_privcmd_resv_pfns(struct vm_area_struct *vma, > > > > int numpgs) > > > ... > > > > + pvhp->pi_num_pgs = numpgs; > > > > + BUG_ON(vma->vm_private_data != (void *)1); > > > > + vma->vm_private_data = pvhp; > > > > > > How does this interact with: > > > > > > static int privcmd_enforce_singleshot_mapping(struct > > > vm_area_struct *vma) { > > > return (xchg(&vma->vm_private_data, (void *)1) == NULL); > > > } > > > > > > If someone tries to map a second time then won't this correct the > > > pvhp in vm_private_data by resetting it to 1? Then when the > > > original mapping is torn down things all fall apart? > > > > > > Perhaps we need a cmpxchg here? Or to rework the callers a little > > > bit perhaps. > > > > 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 :). thanks, Mukesh