UML failing at "Failed to initialize default registers" on kernel 5.10

[Glenn Washburn]

On Mon, 20 Jan 2025 10:56:36 +0100
Benjamin Berg <benjamin at sipsolutions.net> wrote:

> On Mon, 2025-01-20 at 07:07 +0100, Thomas Meyer wrote:
> > 
> > 
> > Am 20. Januar 2025 00:25:35 MEZ schrieb Glenn Washburn
> > <development at efficientek.com>:
> > > Hi Benjamin,
> > > 
> > > After applying the close_range patch, I'm now getting a failure at
> > > runtime where the last line printed from UML is "Failed to
> > > initialize
> > > default registers". The host is on Debian 11 at kernel 5.10.216.
> > > I've
> > > bisected the issue and it looks like the bad commit is: 3f17fed2149
> > > ("um: switch to regset API and depend on XSTATE").
> > > 
> > > On another machine which is on Debian 12 and kernel 6.1.119 the UML
> > > binary compiled from v6.13-rc1 runs fine.
> > > 
> > > I notice that the bad commit appears to be using ptrace in a
> > > different
> > > way. Perhaps there is a difference in how ptrace operate from 5.10
> > > to
> > > 6.1 kernels. I've tried debugging this without much success, as GDB
> > > can't be used. Any idea on what's going on here?
> > 
> > What processor does those machines have?
> 
> Some relatively old CPU or maybe inside a VM?

The failing 5.10 host is not in a VM, infact the 6.1 is in a proxmox
VM. The processor looks like its 15 years old. I suppose that's
relatively old.

Here is the cpuinfo for processor 0:
vendor_id       : GenuineIntel
cpu family      : 6
model           : 44
model name      : Intel(R) Xeon(R) CPU           X5670  @ 2.93GHz
stepping        : 2
microcode       : 0x1f
cpu MHz         : 2926.218
cache size      : 12288 KB
physical id     : 1
siblings        : 12
core id         : 0
cpu cores       : 6
apicid          : 32
initial apicid  : 32
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall
nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor
ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2
popcnt aes lahf_lm epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi
flexpriority ept vpid dtherm ida arat flush_l1d vmx flags       : vnmi
preemption_timer invvpid ept_x_only ept_1gb flexpriority tsc_offset
vtpr mtf vapic ept vpid unrestricted_guest ple bugs            :
cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs
itlb_multihit mmio_unknown bogomips        : 5852.43 clflush size    :
64 cache_alignment : 64 address sizes   : 40 bits physical, 48 bits
virtual power management:

> 
> I would guess it is the same problem as reported by
> https://lore.kernel.org/all/20241203070218.240797-1-sj@kernel.org/
> 
> Please try applying
> https://patch.msgid.link/20241204074827.1582917-1-benjamin@sipsolutions.net
> and check whether that fixes it.

This does indeed fix the issue. Hope this gets picked up in the next
release candidate.

Glenn