Hello Alexander,
[…] So, this is inside dl_iterate_phdr under mutex, as usual, and double mutex call related to search of errno. I suspect other potential code path where we can hit «seach for address of some functions from shared libraries»...
Finally I will remove, as suggested , mutex guard from dl_iterate_phdr completely - while not so sure that this will not lead to error.
Please replace your mutex-remove commit with the following commit [1], which replaces the linker mutex with the shared-object mutex. This behaviour is in line with other dynamic-linkers.
[1] https://github.com/genodelabs/genode/commit/c45d964bc23f4f
(I moved the quotation down a bit to get concise block of text.)
In short, it try to open ld.lib.so (from inside genode), open() fail, and it try to obtain libc errno (via jmp_slot/etc from shared library). So, this is inside dl_iterate_phdr under mutex, as usual, and double mutex call related to search of errno. I suspect other potential code path where we can hit «seach for address of some functions from shared libraries»... Also I add the following to the run file to allow read of ld.lib.so from inside (not sure that this is correct - may be need something else? like direct reference to rom session?) <dir name=«ld.lib.so»> </dir>
In case libbacktrace wants to access other shared-objects directly, besides the binary itself, I would deal with it in the same way, e.g:
! […] ! <vfs> ! <dir name="dev"> <log/> </dir> ! ! <rom name="ld.lib.so"/> ! <rom name="xyz.lib.so"/> ! ! <dir name="proc"> ! <dir name="self"> ! <rom name="exe" label="test-go"/> ! </dir> ! </dir> ! </vfs> ! […]
This config operates under the assumption that libbacktrace wants to access the shared-objects via 'open("/ld.lib.so")' - I have not checked it that's true.
Seems that after that operation my SMP small test with even 4 CPU works somehow (need more extensive tests to be run for golang and goroutunes).
Question: how to verify that removed mutex call does not break something important?
Please just use the commit I referenced above. As far as our automated tests go, it did not introduce any regressions (of course that is no guarantee that all potential corner-cases are covered).
Regards Josef