linux uml segfault

[Anton Ivanov]

On 05/03/2021 18:32, Johannes Berg wrote:
> 
> 
> On 5 March 2021 18:39:42 CET, Anton Ivanov <anton.ivanov at 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/