Re: tunables vs osxsave vs checkpointing vs _dl_runtime_resolve

[Szabolcs Nagy <szabolcs.nagy@arm.com>]

The 03/18/2021 13:18, DJ Delorie via Libc-alpha wrote:
> 
> In response to this customer bug...
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1937515
> 
> I spent some time digging into this code, and was able to reproduce it
> using criu (checkpoint/restore in userspace).  In a nutshell: if you
> create a task on a machine WITH xsave (or xsavec), and migrate it
> (somehow) to a machine WITHOUT xsave (or xsavec), any further DSO
> calls will fail because we've already chosen an xsave/xsavec resolver.
> 
> This, of course, is guaranteed to fail, and cannot be fixed.  With
> criu I had to override the checks with a command line option just to
> prove my point.
> 
> However, if you *know* you might do this, there should be a way to use
> tunables to avoid xsave/xsavec - with the usual caveats about "YMMV" -
> so that a process could be migrated across such CPUs without fault.
> 
> Our tunables almost provide this.

so are we supposed to handle migrations to machines with
different arch extensions?

cpu_features based decisions can break across different
machines and there is no reliable (future proof) way to
request baseline arch features.

on aarch64 the closest is glibc.cpu.name=generic tunable
but it only affects the cpuid (which fixes most libc
ifunc selection logic, but e.g. not if the cpu has bti
or not, there is glibc.cpu.hwcap_mask but not hacap2 mask
so bti cannot be turned off in glibc if the hw has it)