Re: [PATCH] RFC: Provide a function to reset IFUNC PLTs

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 29/03/23 09:12, Jan Kratochvil wrote:
> On Tue, 21 Mar 2023 00:47:53 +0800, Adhemerval Zanella Netto wrote:
>> if I
>> understood it correctly when criu restores a dump it will only restore private
>> mappings from the process and not shared ones?  If so, how does it handle
>> restoring on a system on an older glibc (or on a system with any dependency
>> older than the one that the process was dumped)? Does it only restore file
>> backed shared mappings based on naming?
> 
> Different OS (components) version is not supported, similar to:
> 	https://cr.openjdk.org/~heidinga/crac/Portability_of_checkpoints.pdf
> 	2. Same hardware, different distro

Thanks for the link, so it does seems that CRIU does not save anonymous
file-backed maps, this is what I understood from CRIU memory restore doc [1]
where open file mappings are done by 'files engines' (where I presume it is
either an external process or a library, correct if I am wrong).

Another issue you might see (even on same distro) is that Intel is doing a 
*lot* of performance backports on release branches which means that even 
glibc in the same release version might ended up with different sets
of ifunc variants (since this does not really affect ABI).  I am not sure
how it would reflect on distribution itself, but assuming a distro that
follows the glibc release branch it might indeed happen.

[1] https://criu.org/Memory_dumping_and_restoring	

> 
> 
>> Using a custom built glibc with --disable-multi-arch along with rpath, you
>> have a dissociated glibc from the system.  You can even tune to use an
>> specific x86_64-vX abi if you see that the workload benefits from some
>> specific string/mem/math routine.
> 
> Then I need to build also all other used libraries and that is what is called
> nowadays a container. Which is a perfectly valid use case. But building
> a custom distribution (=glibc) is not a supported way of running any software.
> [This is my personal opinion, I do not speak for any company.]

In fact I think for this specific problem is the best solution.  Along with
a JVM built with rpath, it means you will pack everything it requires and assure
that once it is installed from same package, the glibc won't enable any
optimization not supported and make sure that any distro backport won't
break these assumptions.  It also works with all scenarios you raised, assuming
that 3rd party libraries (outside the JVM package itself) does play nice
in such scenarios.