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

[Jan Kratochvil <jkratochvil@azul.com>]

On Tue, 07 Mar 2023 16:40:46 +0800, Florian Weimer wrote:
> Do you have a high-level overview how this is supposed to work?  Is CRIU
> expected to call the new _dl_reset_ifunc symbol after restore?

Yes, it should be called by CRIU. The current implementation was calling it
from CRaC restore (which uses CRIU underneath) but I agree it is not the
proper placement:
	https://github.com/openjdk/crac/pull/41/files#diff-aeec57d804d56002f26a85359fc4ac8b48cfc249d57c656a30a63fc6bf3457adR6274
The function is called differently there as the IFUNC reset implementation is
outside of glibc there.


> Use of <sys/platform/x86.h> is somewhat rare.  Not even GCC uses it
> AFAIK.  It has its own cached CPU data used for target clones and
> similar features.  Re-running those IFUNC resolvers will just give the
> same results.

I do not use <sys/platform/x86.h> anywhere, why do you mention it?
I am doing there
	memset((volatile uint8_t *)cpu_features, 0, sizeof(*cpu_features));
	...
	_dl_x86_init_cpu_features();
to prevent the cache of CPU data. And it does work.


> Distributions have started to deploy alternate builds in
> glibc-hwcaps/x86-64-v3 directories:
> 
>   openSUSE Tumbleweed gains optional x86-64-v3 optimization
>   <https://news.opensuse.org/2023/03/02/tw-gains-optional-optimizations/>
> 
> This might be a common situation fairly soon.  This is not IFUNC-based
> at all, so any IFUNC-based approach is not going to help with that.

What about some "dlreopen" to replace the variant of glibc?


> Practically speaking, I think cluster heterogeneity needs to be hidden
> at the cluster level.

The question is how to implement it. I have found
	https://github.com/ddcc/libcpuidoverride
but it is not compatible with latest glibc (maybe its loader code needs to
implement ELF relocations, it would be definitely fixable).

Another option is GLIBC_TUNABLES=glibc.cpu.hwcaps=... although then one has to
translate cpuid feature bits into the glibc names like SSE4_2 etc.
Also re-exec() after setenv("GLIBC_TUNABLES") is not too nice.

There are multiple projects solving the same problem such as:
	https://github.com/eclipse-openj9/openj9/issues/14253
So I was thinking some more standardized solution may be already appropriate.


Thanks,
Jan