[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCHv11 3/4] gnttab: make the grant table lock a read-write lock
>>> On 02.06.15 at 18:26, <david.vrabel@xxxxxxxxxx> wrote: > @@ -970,9 +988,10 @@ __gnttab_unmap_common( > TRACE_1D(TRC_MEM_PAGE_GRANT_UNMAP, dom); > > rgt = rd->grant_table; > - double_gt_lock(lgt, rgt); > > - op->flags = op->map->flags; > + read_lock(&rgt->lock); > + > + op->flags = read_atomic(&op->map->flags); > if ( unlikely(!op->flags) || unlikely(op->map->domid != dom) ) > { > gdprintk(XENLOG_WARNING, "Unstable handle %u\n", op->handle); > @@ -1019,31 +1038,34 @@ __gnttab_unmap_common( > act->pin -= GNTPIN_hstw_inc; > } > > - if ( gnttab_need_iommu_mapping(ld) ) > + act_release_out: > + active_entry_release(act); > + unmap_out: > + read_unlock(&rgt->lock); Trying to answer the question on what protects the maptrack entries: With the flags check done first and, after initial setup, the ref field never changing, all modifications of flags as well as the decision whether to drop the maptrack handle appear to be guarded by ref's active entry lock. I think this is implicit enough to require being properly spelled out somewhere. Together with struct grant_mapping not being used elsewhere (I just now created a patch to make this more explicit by moving its declaration to the C file) I think this addresses that particular concern. If you agree, feel free to add Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |