On Mon, Jun 20, 2022 at 02:24:31PM +0100, Jean-Philippe Brucker wrote:Thanks Greg
On Fri, Jun 17, 2022 at 02:05:21PM +0800, Zhangfei Gao wrote:Um, how is rmmod called if the file descriptor is open?
Ah yes sorry, I lost sight of what this patch was adding. But we couldThe refcount only ensures that the uacce_device object is not freed asuacce_remove should wait for uacce->queues_lock, until fops_open release the
long as there are open fds. But uacce_remove() can run while there are
open fds, or fds in the process of being opened. And atfer uacce_remove()
runs, the uacce_device object still exists but is mostly unusable. For
example once the module is freed, uacce->ops is not valid anymore. But
currently uacce_fops_open() may dereference the ops in this case:
uacce_fops_open()
if (!uacce->parent->driver)
/* Still valid, keep going */
... rmmod
uacce_remove()
... free_module()
uacce->ops->get_queue() /* BUG */
lock.
If open happen just after the uacce_remove: unlock, uacce_bind_queue in open
should fail.
have the same issue with the patch, just in a different order, no?
uacce_fops_open()
uacce = xa_load()
... rmmod
That should not be possible if the owner of the file descriptor is
properly set. Please fix that up.