Re: [PATCH v7 rdma-next 1/7] RDMA/core: Move core content from ib_uverbs to ib_core

[Jason Gunthorpe <jgg@ziepe.ca>]

On Tue, Aug 20, 2019 at 03:18:41PM +0300, Michal Kalderon wrote:
> Move functionality that is called by the driver, which is
> related to umap, to a new file that will be linked in ib_core.
> This is a first step in later enabling ib_uverbs to be optional.
> vm_ops is now initialized in ib_uverbs_mmap instead of
> priv_init to avoid having to move all the rdma_umap functions
> as well.

Sneaky, lets please have a comment though

> +/*
> + * Each time we map IO memory into user space this keeps track of the mapping.
> + * When the device is hot-unplugged we 'zap' the mmaps in user space to point
> + * to the zero page and allow the hot unplug to proceed.
> + *
> + * This is necessary for cases like PCI physical hot unplug as the actual BAR
> + * memory may vanish after this and access to it from userspace could MCE.
> + *
> + * RDMA drivers supporting disassociation must have their user space designed
> + * to cope in some way with their IO pages going to the zero page.
> + */
> +void rdma_umap_priv_init(struct rdma_umap_priv *priv,
> +			 struct vm_area_struct *vma)
> +{
> +	struct ib_uverbs_file *ufile = vma->vm_file->private_data;
> +
> +	priv->vma = vma;
> +	vma->vm_private_data = priv;

   /* vm_ops is setup in ib_uverbs_mmap() to avoid module dependencies */

> +
> +	mutex_lock(&ufile->umap_lock);
> +	list_add(&priv->list, &ufile->umaps);
> +	mutex_unlock(&ufile->umap_lock);
> +}
> +EXPORT_SYMBOL(rdma_umap_priv_init);

Does rdma_umap_open need to set ops too, or does the VM initialize it
already?

Jason