linux-rdma.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Michal Kalderon <mkalderon@marvell.com>
Cc: Kamal Heib <kamalheib1@gmail.com>,
	Ariel Elior <aelior@marvell.com>,
	"dledford@redhat.com" <dledford@redhat.com>,
	"galpress@amazon.com" <galpress@amazon.com>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [PATCH v6 rdma-next 1/6] RDMA/core: Create mmap database and cookie helper functions
Date: Thu, 25 Jul 2019 16:52:36 -0300	[thread overview]
Message-ID: <20190725195236.GF7467@ziepe.ca> (raw)
In-Reply-To: <MN2PR18MB3182469DB08CD20B56C9697FA1C10@MN2PR18MB3182.namprd18.prod.outlook.com>

On Thu, Jul 25, 2019 at 07:34:15PM +0000, Michal Kalderon wrote:
> > > +	ibdev_dbg(ucontext->device,
> > > +		  "mmap: obj[0x%p] key[%#llx] addr[%#llx] len[%#llx]
> > removed\n",
> > > +		  entry->obj, key, entry->address, entry->length);
> > > +
> > > +	return entry;
> > > +}
> > > +EXPORT_SYMBOL(rdma_user_mmap_entry_get);
> > 
> > It is a mistake we keep making, and maybe the war is hopelessly lost now,
> > but functions called from a driver should not be part of the ib_uverbs module
> > - ideally uverbs is an optional module. They should be in ib_core.
> > 
> > Maybe put this in ib_core_uverbs.c ?

> But if there isn't ib_uverbs user apps can't be run right ? and then
> these functions Won't get called anyway ?

Right, but, we don't want loading the driver to force creating
/dev/infiniband/uverbs - so the driver support component of uverbs
should live in ib_core, and the /dev/ component should be in ib_uverbs

> > > +	xa_lock(&ucontext->mmap_xa);
> > > +	if (check_add_overflow(ucontext->mmap_xa_page,
> > > +			       (u32)(length >> PAGE_SHIFT),
> > 
> > Should this be divide round up ?

> For cases that length is not rounded to PAGE_SHIFT? 

It should never happen, but yes
 
> > 
> > > +			       &next_mmap_page))
> > > +		goto err_unlock;
> > 
> > I still don't like that this algorithm latches into a permanent failure when the
> > xa_page wraps.
> > 
> > It seems worth spending a bit more time here to tidy this.. Keep using the
> > mmap_xa_page scheme, but instead do something like
> > 
> > alloc_cyclic_range():
> > 
> > while () {
> >    // Find first empty element in a cyclic way
> >    xa_page_first = mmap_xa_page;
> >    xa_find(xa, &xa_page_first, U32_MAX, XA_FREE_MARK)
> > 
> >    // Is there a enough room to have the range?
> >    if (check_add_overflow(xa_page_first, npages, &xa_page_end)) {
> >       mmap_xa_page = 0;
> >       continue;
> >    }
> > 
> >    // See if the element before intersects
> >    elm = xa_find(xa, &zero, xa_page_end, 0);
> >    if (elm && intersects(xa_page_first, xa_page_last, elm->first, elm->last)) {
> >       mmap_xa_page = elm->last + 1;
> >       continue
> >    }
> > 
> >    // xa_page_first -> xa_page_end should now be free
> >    xa_insert(xa, xa_page_start, entry);
> >    mmap_xa_page = xa_page_end + 1;
> >    return xa_page_start;
> > }
> > 
> > Approximately, please check it.

> But we don't free entires from the xa_array ( only when ucontext is destroyed) so how will 
> There be an empty element after we wrap ?  

Oh!

That should be fixed up too, in the general case if a user is
creating/destroying driver objects in loop we don't want memory usage
to be unbounded.

The rdma_user_mmap stuff has VMA ops that can refcount the xa entry
and now that this is core code it is easy enough to harmonize the two
things and track the xa side from the struct rdma_umap_priv

The question is, does EFA or qedr have a use model for this that
allows a userspace verb to create/destroy in a loop? ie do we need to
fix this right now?

Jason

  reply	other threads:[~2019-07-25 19:52 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-09 14:17 [PATCH v6 rdma-next 0/6] RDMA/qedr: Use the doorbell overflow recovery mechanism for RDMA Michal Kalderon
2019-07-09 14:17 ` [PATCH v6 rdma-next 1/6] RDMA/core: Create mmap database and cookie helper functions Michal Kalderon
2019-07-10 12:19   ` Gal Pressman
2019-07-25 17:55   ` Jason Gunthorpe
2019-07-25 19:34     ` Michal Kalderon
2019-07-25 19:52       ` Jason Gunthorpe [this message]
2019-07-26  8:42         ` Michal Kalderon
2019-07-26 13:23           ` Jason Gunthorpe
2019-07-28  8:45             ` Gal Pressman
2019-07-29 14:06               ` Jason Gunthorpe
2019-07-28  9:30     ` Kamal Heib
2019-07-29 14:11       ` Jason Gunthorpe
2019-07-29 12:58     ` Michal Kalderon
2019-07-29 13:53       ` Gal Pressman
2019-07-29 14:04         ` Jason Gunthorpe
2019-07-29 15:26           ` [EXT] " Michal Kalderon
2019-07-29 14:07         ` Michal Kalderon
2019-07-09 14:17 ` [PATCH v6 rdma-next 2/6] RDMA/efa: Use the common mmap_xa helpers Michal Kalderon
2019-07-10 12:09   ` Gal Pressman
2019-07-09 14:17 ` [PATCH v6 rdma-next 3/6] RDMA/qedr: Use the common mmap API Michal Kalderon
2019-07-09 14:17 ` [PATCH v6 rdma-next 4/6] qed*: Change dpi_addr to be denoted with __iomem Michal Kalderon
2019-07-25 18:06   ` Jason Gunthorpe
2019-07-09 14:17 ` [PATCH v6 rdma-next 5/6] RDMA/qedr: Add doorbell overflow recovery support Michal Kalderon
2019-07-25 18:01   ` Jason Gunthorpe
2019-07-25 19:38     ` [EXT] " Michal Kalderon
2019-07-09 14:17 ` [PATCH v6 rdma-next 6/6] RDMA/qedr: Add iWARP doorbell " Michal Kalderon
2019-07-10  7:32 ` [PATCH v6 rdma-next 0/6] RDMA/qedr: Use the doorbell overflow recovery mechanism for RDMA Gal Pressman
2019-07-11  7:23   ` Michal Kalderon
2019-07-25 18:01 ` Jason Gunthorpe
2019-07-25 19:40   ` [EXT] " Michal Kalderon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190725195236.GF7467@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=aelior@marvell.com \
    --cc=davem@davemloft.net \
    --cc=dledford@redhat.com \
    --cc=galpress@amazon.com \
    --cc=kamalheib1@gmail.com \
    --cc=linux-rdma@vger.kernel.org \
    --cc=mkalderon@marvell.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).