Re: linux uml segfault

From: Anton Ivanov <anton.ivanov@kot-begemot.co.uk>
To: Benjamin Berg <benjamin@sipsolutions.net>,
	Johannes Berg <johannes@sipsolutions.net>,
	Hajime Tazaki <thehajime@gmail.com>
Cc: rrs@debian.org, chris.obbard@collabora.com,
	linux-um@lists.infradead.org, 983379@bugs.debian.org
Subject: Re: linux uml segfault
Date: Thu, 4 Mar 2021 18:41:45 +0000	[thread overview]
Message-ID: <fdbe84e1-ab45-7eb4-7aa7-5ba9798be633@kot-begemot.co.uk> (raw)
In-Reply-To: <19322b1442a7fc5938e026cb4eccc113a7c2328b.camel@sipsolutions.net>

On 04/03/2021 08:05, Benjamin Berg wrote:
> On Thu, 2021-03-04 at 08:47 +0100, 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.
> 
> Maybe using the ld --version-script= option here works to mark all
> kernel symbols as being "local" and prevent them from being picked up
> by libraries.
> 
> Benjamin
> 
>> 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?

I can confirm that it did and this bug is bisect-able.

with 5.7

# dd if=/dev/ubda of=/dev/null bs=1M
16384+1 records in
16384+1 records out
17179869696 bytes (17 GB, 16 GiB) copied, 10.6973 s, 1.6 GB/s

with 5.10 the speed is 2.2
5.7 with "strings from glibc" patch speed is 2.2

As we did not do anything else in this timeframe to jack up the speed from 1.6GB/s to 2.2GB/s and as it is identical to the speed you get with the "use glibc strings.h" this looks like a good criteria to bisect on.

I am going to do a bisect with 5.7 "good" and 5.10 "bad" using the speed test as a working hypothesis.

A.

> 
> johannes
> 
> 
> _______________________________________________
> linux-um mailing list
> linux-um@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-um
> 
> 
> 
> _______________________________________________
> linux-um mailing list
> linux-um@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-um
> 

-- 
Anton R. Ivanov
https://www.kot-begemot.co.uk/

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um