[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v5 5/7] VT-d: Refactor iommu_ops .map_page() and unmap_page()



>>> On 26.02.16 at 09:14, <JBeulich@xxxxxxxx> wrote:
> Nevertheless I'd recommend not mixing things for the pcidevs
> one, as its uses are scattered around too much for it to be
> reasonably possible to prove correctness if done that way.
> Instead please make the lock a static variable in e.g.
> xen/drivers/pci/pci.c or xen/drivers/passthrough/pci.c, and
> force acquire/release to go through helper functions. That
> way we can ensure instance gets left. The only safe alternative
> to this would be to rename the lock at once, or to make it
> read/write one (but then recursion would be allowed only for
> the read cases, and aiui you'd need the write variant for your
> use).

Actually, not even that - as of the XSA-114 fix we don't allow
reader recursion anymore. (I wonder whether we have any
latent issue in the tree due to that, since I don't recall anyone
having audited all r/w lock uses back then.)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.