Re: [PATCH v4 for-next 1/2] RDMA/core: Provide rdma_user_mmap_disassociate() to disassociate mmap pages
From: Jason Gunthorpe
Date: Sat Sep 07 2024 - 08:12:18 EST
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