[openib-general] [RFC] [PATCH 1/3] RDMA CM: add rdma_get/set_optioncalls to get/set path records

[Sean Hefty]

Michael S. Tsirkin wrote:
>>The getsockopt / setsockopt calls both use char *optval in their 
>>interfaces. Internally, they do get_user(), put_user(), copy_to_user(), etc.
>>
>>It's my understanding, which could be way off, that both getsockopt and 
>>setsockopt are also callable from kernel modules.  I have not had a chance 
>>to try these calls with kernel memory to see what copy_to_user() would do.
> 
> 
> I think this works on typical intel, but not so sure about other architectures.
> You might need to be in process context so that current pointer is valid.

I did just test this, and it worked at least on my systems.  I couldn't find 
anywhere in the kernel where s/getsockopt would be called without doing a 
get_user / put_user.  Maybe one of the iWarp developers can help here?  Is there 
a separate implementation of s/getsockopt for kernel users, versus userspace users?

> How about doing copy_from_user in ucma, and implementing
> rdma_set_path/rdma_get_path in cma?

I don't think that we want to start adding a new set of APIs for every option 
that may eventually need to be supported.  I _might_ be able to move the 
implementation into the ucma, but this would duplicate the s/get_option logic in 
both in ucma and cma.

Regarding getting path records.  For a large subnet, the number of paths can be 
fairly large, so I'd like to avoid multiple data copies.  I also want to avoid 
needing to allocate a large kernel buffer (which may require a list of 
allocations) to get the paths to return to userspace.

- Sean