On Thu, Oct 6, 2022 at 8:20 PM Linus Torvalds torvalds@linux-foundation.org wrote:
On Wed, Oct 5, 2022 at 11:24 PM Sumit Garg sumit.garg@linaro.org wrote:
Sorry but you need to get your driver mainline in order to support vmalloc interface.
Actually, I think even then we shouldn't support vmalloc - and register_shm_helper() just needs to be changed to pass in an array of actual page pointers instead.
register_shm_helper() is an internal function, I suppose it's what's passed to tee_shm_register_user_buf() and especially tee_shm_register_kernel_buf() in this case.
So the gain is that in the kernel it becomes the caller's responsibility to provide the array of page pointers and the TEE subsystem doesn't need to care about what kind of kernel memory it is any longer. Yes, that should avoid eventual complexities with vmalloc() etc.
At that point TEE_SHM_USER_MAPPED should also go away, because then it's the caller that should just do either the user space page pinning, or pass in the kernel page pointer.
JensW, is there some reason that wouldn't work?
We still need to know if it's kernel or user pages in release_registered_pages().
The struct tee_shm:s acquired with syscalls from user space are reference counted. As are the kernel tee_shm:s, but I believe we could separate them to avoid reference counting tee_shm:s used by kernel clients if needed. I'll need to look closer at this if we're going to use that approach.
Without reference counting the caller of tee_shm_free() can be certain that the secure world is done with the memory so we could delegate the kernel pages part of release_registered_pages() to the caller instead.
Cheers, Jens
Linus