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
