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
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
