zsock_getaddrinfo() is not reentrant

[andrewboie]

This function uses globals for the returned address information (ai_arr) as well as a global for the state of the getaddrinfo function (ai_state). This presents some problems:

1. Multiple threads calling zsock_getaddrinfo() concurrently could lead to data corruption, either in ai_state or ai_arr or both. ai_state could be moved onto zsock_getaddrinfo's stack instead of being a global, but ai_arr is more complicated.
2. The returned "res" pointer is supposed to be allocated. Right now, we cannot expose zsock_getaddrinfo() to user mode as user mode would not have access to ai_arr. What we need is something like malloc()/free() in minimal libc, possibly backed with the sys_mem_pool implementation.

[pfalcon]

as user mode would not have access to ai_arr

A quick workaround might be allowing to define variable in "kernel sources" which would go into userspace .data/.bss?

[pfalcon]

Otherwise, yes, from http://pubs.opengroup.org/onlinepubs/9699919799/functions/getaddrinfo.html:

The freeaddrinfo() and getaddrinfo() functions shall be thread-safe.

[andrewboie]

A quick workaround might be allowing to define variable in "kernel sources" which would go into userspace .data/.bss?

No easy way to do this unfortunately. Userspace doesn't get access to any RAM outside of its own stack unless such RAM is configured in a memory domain: http://docs.zephyrproject.org/kernel/usermode/memory_domain.html

We don't have any good options (yet):

• We support malloc()/free() in newlib. There's a function z_newlib_get_heap_bounds() which returns the necessary data to add a partition to a thread's memory domain representing the newlib heap. There's just one heap for all threads. malloc/free don't work well in a world of partitioned physical memory addresses unfortunately.
• No malloc/free in minimal libc. We could potentially implement this with a sys_mem_pool.

We do have the notion of thread "resource pools", where threads are assigned a k_mem_pool which is used for temporary memory allocations done on behalf of system calls. But this mechanism is for private kernel data, such allocations are never intended to return to the caller.

I'm going to spend some time today contemplating this, until now we didn't have any syscalls which needed to allocate memory and give it to the caller, I expect this situation will arise again.

[pfalcon]

Userspace doesn't get access to any RAM outside of its own stack

How global and static vars in userspace are handled then?

[andrewboie]

How global and static vars in userspace are handled then?

For test cases we have a feature called CONFIG_APPLICATION_MEMORY which takes all globals which are part of the application (based on location of the object file) and places them in a special section which is then granted access to all user threads. It's a stopgap measure to get test cases up and running quickly.

A real-world use-case with multiple logical applications on the same MCU would place all their globals in special linker sections, a design under consideration is #7632

[pfalcon]

This was fixed by #9016.