On Wed, Sep 14, 2022 at 06:11:06AM -0300, Jason Gunthorpe wrote:

On Tue, Sep 13, 2022 at 01:27:03PM +0100, Jean-Philippe Brucker wrote:

quoted

I think in the future it will be too easy to forget about the constrained
return value of attach() while modifying some other part of the driver,
and let an external helper return EINVAL. So I'd rather not propagate ret
from outside of viommu_domain_attach() and finalise().

Fortunately, if -EINVAL is wrongly returned it only creates an
inefficiency, not a functional problem. So we do not need to be
precise here.

Ah fair. In that case the attach_dev() documentation should indicate that
EINVAL is a hint, so that callers don't rely on it (currently words "must"
and "exclusively" indicate that returning EINVAL for anything other than
device-domain incompatibility is unacceptable). The virtio-iommu
implementation may well return EINVAL from the virtio stack or from the
host response.

Thanks,
Jean

quoted

Since we can't guarantee that APIs like virtio or ida won't ever return
EINVAL, we should set all return values:

I dislike this alot, it squashes all return codes to try to optimize
an obscure failure path :(

Jason

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel