Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation
From: Timur Tabi
Date: Mon Apr 25 2005 - 21:22:23 EST
Andrew Morton wrote:
RLIMIT_MEMLOCK sounds like the appropriate mechanism. We cannot rely upon
userspace running mlock(), so perhaps it is appropriate to run sys_mlock()
in-kernel because that gives us the appropriate RLIMIT_MEMLOCK checking.
I don't see what's wrong with relying on userspace to call mlock(). First all, all RDMA
apps call a third-party API, like DAPL or MPI, to register memory. The memory needs to be
registered in order for the driver and adapter to know where it is. During this
registration, the memory is also pinned. That's when we call mlock().
However an hostile app can just go and run munlock() and then allocate
some more pinned-by-get_user_pages() memory.
Isn't mlock() on a per-process basis anyway? How can one process call munlock() on
another process' memory?
umm, how about we
- force the special pages into a separate vma
- run get_user_pages() against it all
- use RLIMIT_MEMLOCK accounting to check whether the user is allowed to
do this thing
- undo the RMLIMIT_MEMLOCK accounting in ->release
Isn't this kinda what mlock() does already? Create a new VMA and then VM_LOCK it?
This will all interact with user-initiated mlock/munlock in messy ways.
Maybe a new kernel-internal vma->vm_flag which works like VM_LOCKED but is
unaffected by mlock/munlock activity is needed.
A bit of generalisation in do_mlock() should suit?
Yes, but do_mlock() needs to prevent pages from being moved during memory hotswap.
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/