[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCHv6 4/5] gnttab: remove unnecessary grant table locks
>>> On 22.04.15 at 18:00, <david.vrabel@xxxxxxxxxx> wrote: > This is safe because: a) the grant table version only changes once > from 0 to 1 or 2; gnttab_set_version() also allows it to transition between 1 and 2 afaics. > @@ -919,18 +914,15 @@ __gnttab_unmap_common( > } > > op->map = &maptrack_entry(lgt, op->handle); > - spin_lock(&lgt->lock); > > if ( unlikely(!op->map->flags) ) > { > - spin_unlock(&lgt->lock); > gdprintk(XENLOG_INFO, "Zero flags for handle (%d).\n", op->handle); > op->status = GNTST_bad_handle; > return; > } > > dom = op->map->domid; > - spin_unlock(&lgt->lock); Don't you need a lock here to see a consistent op->map->{dom,ref,flags} tuple (with the writing side also holding a lock while updating them)? > @@ -952,7 +944,6 @@ __gnttab_unmap_common( > > rgt = rd->grant_table; > > - spin_lock(&rgt->lock); > act = active_entry_acquire(rgt, op->map->ref); > > op->flags = op->map->flags; Same here then. > @@ -1423,7 +1410,17 @@ gnttab_setup_table( > } > > gt = d->grant_table; > - spin_lock(>->lock); > + > + /* Tracking of mapped foreign frames table */ > + if ( (gt->maptrack = xzalloc_array(struct grant_mapping *, > + max_maptrack_frames * d->max_vcpus)) > == NULL ) > + goto out2; This provides no error indication to the caller. And is this allocation guaranteed to be no larger than a page? Finally - does this belong here (and not instead into the last patch)? > @@ -114,13 +114,13 @@ gnttab_grow_table(struct domain *d, unsigned int > req_nr_frames); > /* Number of grant table frames. Caller must hold d's grant table lock. */ > static inline unsigned int nr_grant_frames(struct grant_table *gt) > { > - return gt->nr_grant_frames; > + return atomic_read(>->nr_grant_frames); > } > > /* Number of status grant table frames. Caller must hold d's gr. table > lock.*/ > static inline unsigned int nr_status_frames(struct grant_table *gt) > { > - return gt->nr_status_frames; > + return atomic_read(>->nr_status_frames); > } Both comments need changing. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |