Re: [openib-general] Re: [PATCH][RFC][0/4] InfiniBand userspaceverbs implementation
From: Andrew Morton
Date: Mon Apr 25 2005 - 18:28:00 EST
Libor Michalek <libor@xxxxxxxxxxx> wrote:
> On Mon, Apr 25, 2005 at 03:35:42PM -0700, Andrew Morton wrote:
> > Timur Tabi <timur.tabi@xxxxxxxxxxx> wrote:
> > >
> > > Andrew Morton wrote:
> > >
> > > > The way we expect get_user_pages() to be used is that the kernel will use
> > > > get_user_pages() once per application I/O request.
> > >
> > > Are you saying that the mapping obtained by get_user_pages() is valid only within the
> > > context of the IOCtl call? That once the driver returns from the IOCtl, the mapping
> > > should no longer be used?
> > Yes, we expect that all the pages which get_user_pages() pinned will become
> > unpinned within the context of the syscall which pinned the pages. Or
> > shortly after, in the case of async I/O.
> When a network protocol is making use of async I/O the amount of time
> between posting the read request and getting the completion for that
> request is unbounded since it depends on the other half of the connection
> sending some data. In this case the buffer that was pinned during the
> io_submit() may be pinned, and holding the pages, for a long time.
> this time the process might fork, at this point any data received will be
> placed into the wrong spot.
Well the data is placed in _a_ spot. That's only the "wrong" spot because
you've defined it to be wrong!
IOW: what behaviour are you actually looking for here, and why, and does it
> > This is because there is no file descriptor or anything else associated
> > with the pages which permits the kernel to clean stuff up on unclean
> > application exit. Also there are the obvious issues with permitting
> > pinning of unbounded amounts of memory.
> Correct, the driver must be able to determine that the process has died
> and clean up after it, so the pinned region in most implementations is
> associated with an open file descriptor.
How is that association created?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/