Re: [RFC PATCH 12/18] aarch64: fix AARCH64_FLOAT_STATE save/restore and setstatus alignment

On Tue, May 26, 2026 at 8:45 AM Paulo Fernando Barbosa Duarte
<[email protected]> wrote:
> On 24 May 2026, at 21:55, Jessica Clarke <[email protected]> wrote:
> > Would it not be more appropriate to fix MIG to respect alignment
> > requirements rather than hack around it by ignoring the unaligned data?

> Jessica, I investigated it and unfortunately this alignment issue cannot be solved by MIG alone,
> the current used RPC pass the data to the kernel in a byte array and the alignment is incorrect.
> I managed to add support to int __128 locally, but I would still need create a new RPC to ensure
> the alignment, the main issue is this would require to many ports in a lot of userspace, so I
> decided not to go in that direction.

> Sergey your input here would also be appreciated.

I don't really remember :|

Jess is right that generally, fixing the underlying cause is better
than adding workarounds. But in this case, thread_set_state is a
generic API that is defined to work on a thread_state_t, which is an
array[*:1024] of natural_t. So MIG cannot be blamed for not aligning
it for int128.

What I don't remember is how MIG decides whether to pass data in-line
or out-of-line. Is it dependent on size (i.e. new_state_count)? And if
the data is transferred out-of-line, does the kernel just get a
pointer into the user's page? -- possibly unaligned?

Also pay attention to thread_set_self_state, that too only does
natural_t alignment. And that evidently worked for me, since sigreturn
definitely restores the float registers state (see
sysdeps/mach/hurd/aarch64/sigreturn.c:__sigreturn2).

I wonder, does your compiler perhaps want a different alignment for
__int128 than mine did? Are you (not) using aarch64-gnu-gcc?

Sergey