On 2/28/23 9:51 PM, Jason Gunthorpe wrote:
On Tue, Feb 28, 2023 at 09:50:52AM +0800, Baolu Lu wrote:
On 2/27/23 9:58 PM, Jason Gunthorpe wrote:
On Sun, Feb 26, 2023 at 11:01:59AM +0800, Baolu Lu wrote:
On 2/25/23 8:27 AM, Jason Gunthorpe wrote:
@@ -437,25 +517,77 @@ int iommufd_device_attach(struct iommufd_device *idev, u32 *pt_id) struct iommufd_ioas *ioas = container_of(pt_obj, struct iommufd_ioas, obj);
rc = iommufd_device_auto_get_domain(idev, ioas, pt_id);if (rc)
destroy_hwpt = iommufd_device_auto_get_domain(idev, ioas, pt_id,do_attach);if (IS_ERR(destroy_hwpt)) goto out_put_pt_obj; break; } default:
rc = -EINVAL;
destroy_hwpt = ERR_PTR(-EINVAL); goto out_put_pt_obj; }- iommufd_put_object(pt_obj);
- refcount_inc(&idev->obj.users);
- rc = 0;
- /* This destruction has to be after we unlock everything */
- if (destroy_hwpt)
Should this be
if (!IS_ERR_OR_NULL(destroy_hwpt))
?
Never use IS_ERR_OR_NULL ..
Can you please elaborate a bit on this? I can still see a lot of use of it in the tree.
Yes, sadly. It is usually some signal of toxic confusion about what things mean.
A function that returns an ERR_PTR should very rarely return NULL, and if it does return NULL then NULL wasn't an error.
That's true.
Further you should never store an ERR_PTR in some structure and then later try to test it, that is madness.
So with properly structured code the need should not exist.
https://lore.kernel.org/all/20130109150427.GL3931@n2100.arm.linux.org.uk/
It's clear to me now. Thanks a lot for the explanation.
Best regards, baolu