Re: [PATCH][RFC][0/4] InfiniBand userspace verbs implementation

[Timur Tabi <timur.tabi@ammasso.com>]

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/