[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BN9PR11MB5276E1CE6E46DFC61B982D3F8C4BA@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Fri, 11 Jul 2025 03:18:53 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Nicolin Chen <nicolinc@...dia.com>, "jgg@...dia.com" <jgg@...dia.com>
CC: "yilun.xu@...ux.intel.com" <yilun.xu@...ux.intel.com>,
"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] iommufd: Do not allow _iommufd_object_alloc_ucmd if abort
op is set
> From: Nicolin Chen <nicolinc@...dia.com>
> Sent: Friday, July 11, 2025 4:24 AM
>
> An abort op was introduced to allow its caller to invoke it within a lock
> in the caller's function. On the other hand, _iommufd_object_alloc_ucmd()
> would invoke the abort op in iommufd_object_abort_and_destroy() that
> must
> be outside the caller's lock. So, these two cannot work together.
>
> Add a validation in the _iommufd_object_alloc_ucmd(). Pick -EOPNOTSUPP
> to
> reject the function call, indicating that the object allocator is buggy.
>
> Suggested-by: Xu Yilun <yilun.xu@...ux.intel.com>
> Signed-off-by: Nicolin Chen <nicolinc@...dia.com>
Reviewed-by: Kevin Tian <kevin.tian@...el.com>
Powered by blists - more mailing lists