On Thu, Sep 05, 2024 at 09:11:54PM +0800, Junxian Huang wrote: > @@ -698,11 +700,20 @@ static int ib_uverbs_mmap(struct file *filp, struct vm_area_struct *vma) > ucontext = ib_uverbs_get_ucontext_file(file); > if (IS_ERR(ucontext)) { > ret = PTR_ERR(ucontext); > - goto out; > + goto out_srcu; > } > + > + mutex_lock(&file->disassociation_lock); > + if (file->disassociated) { > + ret = -EPERM; > + goto out_mutex; > + } What sets disassociated back to false once the driver reset is completed? I think you should probably drop this and instead add a lock and test inside the driver within its mmap op. While reset is ongoing fail all new mmaps. > /* > * Disassociation already completed, the VMA should already be zapped. > */ > - if (!ufile->ucontext) > + if (!ufile->ucontext || ufile->disassociated) > goto out_unlock; Is this needed? It protects agains fork, but since the driver is still present I wonder if it is OK > @@ -822,6 +837,8 @@ void uverbs_user_mmap_disassociate(struct ib_uverbs_file *ufile) > struct rdma_umap_priv *priv, *next_priv; > > lockdep_assert_held(&ufile->hw_destroy_rwsem); > + mutex_lock(&ufile->disassociation_lock); > + ufile->disassociated = true; I think this doesn't need the hw_destroy_rwsem anymore since you are using this new disassociation_lock instead. It doesn't make alot of sense to hold the hw_destroy_rwsem for read here, it was ment to be held for write. Jason