Timur Tabi <[EMAIL PROTECTED]> wrote: > > Andrew Morton wrote: > > > 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. > > Then that might explain the "bug" that we're seeing with get_user_pages(). > We've been > assuming that get_user_pages() mappings are permanent.
They are permanent until someone runs put_page() against all the pages. What I'm saying is that all current callers of get_user_pages() _do_ run put_page() within the same syscall or upon I/O termination. > Well, I was just about to re-implement get_user_pages() support in our driver > to > demonstrate the bug. I guess I'll hold off on that. > > If you look at the Infiniband code that was recently submitted, I think > you'll see it does > exactly that: after calling mlock(), the driver calls get_user_pages(), and > it stores the > page mappings for future use. Where? bix:/usr/src/linux-2.6.12-rc3> grep -rl get_user_pages . ./arch/i386/lib/usercopy.c ./arch/sparc64/kernel/ptrace.c ./drivers/video/pvr2fb.c ./drivers/media/video/video-buf.c ./drivers/scsi/sg.c ./drivers/scsi/st.c ./include/asm-ia64/pgtable.h ./include/linux/mm.h ./include/asm-um/archparam-i386.h ./include/asm-i386/fixmap.h ./fs/nfs/direct.c ./fs/aio.c ./fs/binfmt_elf.c ./fs/bio.c ./fs/direct-io.c ./kernel/futex.c ./kernel/ptrace.c ./mm/memory.c ./mm/nommu.c ./mm/rmap.c ./mm/mempolicy.c _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
