Messages in this thread | | | Date | Mon, 25 Apr 2005 16:24:05 -0700 | From | Andrew Morton <> | Subject | Re: [openib-general] Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation |
| |
Libor Michalek <libor@topspin.com> wrote: > > On Mon, Apr 25, 2005 at 03:35:42PM -0700, Andrew Morton wrote: > > Timur Tabi <timur.tabi@ammasso.com> 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.
Sure.
> During > 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 matter?
> > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |