Libor Michalek <[EMAIL PROTECTED]> wrote: > > On Mon, Apr 25, 2005 at 03:35:42PM -0700, Andrew Morton wrote: > > Timur Tabi <[EMAIL PROTECTED]> 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? _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
