kernel/linux.git/drivers/misc/uacce, branch v6.19.11

uacce: ensure safe queue release with state management

2026-01-16T15:43:17+00:00

Directly calling `put_queue` carries risks since it cannot guarantee that resources of `uacce_queue` have been fully released beforehand. So adding a `stop_queue` operation for the UACCE_CMD_PUT_Q command and leaving the `put_queue` operation to the final resource release ensures safety. Queue states are defined as follows: - UACCE_Q_ZOMBIE: Initial state - UACCE_Q_INIT: After opening `uacce` - UACCE_Q_STARTED: After `start` is issued via `ioctl` When executing `poweroff -f` in virt while accelerator are still working, `uacce_fops_release` and `uacce_remove` may execute concurrently. This can cause `uacce_put_queue` within `uacce_fops_release` to access a NULL `ops` pointer. Therefore, add state checks to prevent accessing freed pointers. Fixes: 015d239ac014 ("uacce: add uacce driver") Cc: stable@vger.kernel.org Signed-off-by: Chenghai Huang Signed-off-by: Yang Shen Acked-by: Zhangfei Gao Link: https://patch.msgid.link/20251202061256.4158641-5-huangchenghai2@huawei.com Signed-off-by: Greg Kroah-Hartman

uacce: implement mremap in uacce_vm_ops to return -EPERM

2026-01-16T15:43:16+00:00

The current uacce_vm_ops does not support the mremap operation of vm_operations_struct. Implement .mremap to return -EPERM to remind users. The reason we need to explicitly disable mremap is that when the driver does not implement .mremap, it uses the default mremap method. This could lead to a risk scenario: An application might first mmap address p1, then mremap to p2, followed by munmap(p1), and finally munmap(p2). Since the default mremap copies the original vma's vm_private_data (i.e., q) to the new vma, both munmap operations would trigger vma_close, causing q->qfr to be freed twice(qfr will be set to null here, so repeated release is ok). Fixes: 015d239ac014 ("uacce: add uacce driver") Cc: stable@vger.kernel.org Signed-off-by: Yang Shen Signed-off-by: Chenghai Huang Acked-by: Zhangfei Gao Link: https://patch.msgid.link/20251202061256.4158641-4-huangchenghai2@huawei.com Signed-off-by: Greg Kroah-Hartman

uacce: fix isolate sysfs check condition

2026-01-16T15:43:16+00:00

uacce supports the device isolation feature. If the driver implements the isolate_err_threshold_read and isolate_err_threshold_write callback functions, uacce will create sysfs files now. Users can read and configure the isolation policy through sysfs. Currently, sysfs files are created as long as either isolate_err_threshold_read or isolate_err_threshold_write callback functions are present. However, accessing a non-existent callback function may cause the system to crash. Therefore, intercept the creation of sysfs if neither read nor write exists; create sysfs if either is supported, but intercept unsupported operations at the call site. Fixes: e3e289fbc0b5 ("uacce: supports device isolation feature") Cc: stable@vger.kernel.org Signed-off-by: Chenghai Huang Acked-by: Zhangfei Gao Link: https://patch.msgid.link/20251202061256.4158641-3-huangchenghai2@huawei.com Signed-off-by: Greg Kroah-Hartman

uacce: fix cdev handling in the cleanup path

2026-01-16T15:43:16+00:00

When cdev_device_add fails, it internally releases the cdev memory, and if cdev_device_del is then executed, it will cause a hang error. To fix it, we check the return value of cdev_device_add() and clear uacce->cdev to avoid calling cdev_device_del in the uacce_remove. Fixes: 015d239ac014 ("uacce: add uacce driver") Cc: stable@vger.kernel.org Signed-off-by: Wenkai Lin Signed-off-by: Chenghai Huang Acked-by: Zhangfei Gao Link: https://patch.msgid.link/20251202061256.4158641-2-huangchenghai2@huawei.com Signed-off-by: Greg Kroah-Hartman

uacce: Remove unnecessary IOMMU_DEV_FEAT_IOPF

2025-04-28T11:04:34+00:00

None of the drivers implement anything for IOMMU_DEV_FEAT_IOPF anymore, remove it to avoid dead code. Signed-off-by: Lu Baolu Reviewed-by: Jason Gunthorpe Reviewed-by: Kevin Tian Acked-by: Zhangfei Gao Tested-by: Zhangfei Gao Link: https://lore.kernel.org/r/20250418080130.1844424-7-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel

iommu: Remove IOMMU_DEV_FEAT_SVA

2025-04-28T11:04:29+00:00

None of the drivers implement anything here anymore, remove the dead code. Signed-off-by: Jason Gunthorpe Signed-off-by: Lu Baolu Reviewed-by: Kevin Tian Reviewed-by: Yi Liu Tested-by: Zhangfei Gao Link: https://lore.kernel.org/r/20250418080130.1844424-3-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel

uacce: make uacce_class constant

2023-10-27T06:51:00+00:00

Now that the driver core allows for struct class to be in read-only memory, we should make all 'class' structures declared at build time placing them into read-only memory, instead of having to be dynamically allocated at runtime. Cc: Zhou Wang Cc: Arnd Bergmann Cc: linux-accelerators@lists.ozlabs.org Tested-by: Zhangfei Gao Link: https://lore.kernel.org/r/2023102458-designate-vicinity-4c86@gregkh Signed-off-by: Greg Kroah-Hartman

uacce: vma_close clears q->qfrs when freeing qfrs

2023-05-31T18:00:26+00:00

vma_close frees qfrs but not clears q->qfrs, which still points to the freed object, leading to subsequent mmap fail. So vma_close clears q->qfrs as well. Suggested-by: Al Viro Signed-off-by: Zhangfei Gao Link: https://lore.kernel.org/r/20230511095921.9331-3-zhangfei.gao@linaro.org Signed-off-by: Greg Kroah-Hartman

uacce: use q->mapping to replace inode->i_mapping

2023-05-31T18:00:26+00:00

The inode can be different in a container, for example, a docker and host both open the same uacce parent device, which uses the same uacce struct but different inode, so uacce->inode is not enough. What's worse, when docker stops, the inode will be destroyed as well, causing use-after-free in uacce_remove. So use q->mapping to replace uacce->inode->i_mapping. Signed-off-by: Weili Qian Signed-off-by: Zhangfei Gao Link: https://lore.kernel.org/r/20230511095921.9331-2-zhangfei.gao@linaro.org Signed-off-by: Greg Kroah-Hartman

driver core: class: remove module * from class_create()

2023-03-17T14:16:33+00:00

The module pointer in class_create() never actually did anything, and it shouldn't have been requred to be set as a parameter even if it did something. So just remove it and fix up all callers of the function in the kernel tree at the same time. Cc: "Rafael J. Wysocki" Acked-by: Benjamin Tissoires Link: https://lore.kernel.org/r/20230313181843.1207845-4-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman