> From: linux-rdma-owner@xxxxxxxxxxxxxxx <linux-rdma-
> owner@xxxxxxxxxxxxxxx> On Behalf Of Jason Gunthorpe
>
> 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
>
Sure, will add.
> > +/*
> > + * 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 */
ok
>
> > +
> > + 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?
Will double check
>
> Jason
