On 05/03/2021 18:32, Johannes Berg wrote:
On 5 March 2021 18:39:42 CET, Anton Ivanov <anton.iva...@kot-begemot.co.uk>
wrote:
On 04/03/2021 07:47, Johannes Berg wrote:
On Thu, 2021-03-04 at 14:38 +0900, Hajime Tazaki wrote:
Now, I don't know how to fix it (short of changing your nsswitch
configuration) - maybe we could somehow rename sem_init()? Or maybe
we
can somehow give the kernel binary a lower symbol resolution than
the
libc/libpthread.
objcopy (from binutils) can localize symbols (i.e., objcopy -L
sem_init $orig_file $new_file). It also does renaming symbols. But
not sure this is the ideal solution.
Yes, we started thinking about it but it was too late at night when I
replied ...
I think there's basically a way to have an external list of symbols
to
export, for symbol versioning, that we could/should use to basically
not
export any of the kernel symbols out to libs.
How does UML handle symbol conflicts between userspace code and
Linux
kernel (like this case sem_init) ? AFAIK, libnl has a same symbol
as
Linux kernel (genlmsg_put) and others can possibly do as well.
I fear it doesn't?
Let's assume it does not, and try to fix this by de-conflicting the
symbol.
For the time being, also, let's aim for a Debian specific patch just to
go into their "patches" dir for build so that UML is not dropped out of
the release.
This should make all internal uses of sem_init be um_sem_init in the
actual object files. I will chase the issue of it picking up glibc
memcpy separately.
Upon close inspection it looks like a different issue - it is in the
other direction (picking a dynamic symbol instead of the one from the
tree). I spent all day chasing it today and I cannot reproduce it. At
the same time it was reproducible yesterday without any problems :(
+#ifdef CONFIG_UML
+void __init um_sem_init(void)
+#else
void __init sem_init(void)
+#endif
Might be easier to just
#define sem_init um_sem_init
in an appropriate header file, perhaps even in arch/um/?
I thought of that, but surrendered to the "dark side" of the quick and ugly fix.
We can do that for the ipc/sem.c - it brings in uaccess.h which ultimately
pulls uaccess from our asm tree. So if we do it there, it will end up in sem.c
However, that function is also referenced and is invoked out of ipc/util.c
which does not pull that include.
I am going to dig through the rest of our includes to see if we can find a suitable one
which will be picked up by both sem.c and util.c. I hope there is a place which we can
use for a "proper" fix.
By the way, I actually remember seeing a couple of includes like that somewhere
dealing with other um symbol conflicts, just can't remember where I saw it.
johannes
--
Anton R. Ivanov
https://www.kot-begemot.co.uk/
