bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH mig] Make MIG work for pure 64 bit kernel and userland.


From: Sergey Bugaev
Subject: Re: [PATCH mig] Make MIG work for pure 64 bit kernel and userland.
Date: Fri, 17 Feb 2023 11:27:29 +0300

> With this layout alignment issues seem much simpler to solve, basically
> we can leave the compiler find the best combination for the second part
> of the message, and if the user/kernel archs are the same, the struct
> will have the same layout in the sending and receiving mig stubs.

To be clear: I do *not* propose to switch GNU Mach / MIG to untyped
IPC. While there are benefits to untyped IPC, there are downsides too.
For one, that would break rpctrace, since it won't be able to
introspect the message bodies. (This sounds like a perfect cue to brag
about XtraceMig, but I will resist the temptation :)

So better let's make typed MIG work well on 64-bit.

> One last thing though, we should still make sure that the struct
> starting address is correctly aligned, right? Otherwise this could blow
> up all the compiler's effort to find the correct alignment for the
> internal fields.

Yes. I hear that the x86 family hardware can handle unaligned accesses
just fine (if slower than aligned accesses), but it is immediate
Undefined Behavior on the C language level to even create an
improperly aligned pointer.

> I see that a kmsg is allocated with kalloc, so I guess that we need
> somehow to make sure that kalloc returns a memory chunk with the correct
> alignment. But from what I can see from a quick look, it seems that no
> particular alignment is enforced (i.e. where available, align=0).
>
> Is this correct? Or did I miss something?

Well, in userland, malloc() is defined to "return a pointer to the
allocated memory, which is suitably aligned for any type that fits
into the requested size or less" -- in other words, malloc always
returns "maximally" (i.e. 16-bytes) aligned buffers (except possibly
when the requested size is smaller). It would be reasonable to expect
kalloc() to also provide the same guarantee, and indeed I can see that
kalloc() uses either page allocation or the kmem_cache, and kmem_cache
always aligns to at least KMEM_ALIGN_MIN, which is 8. Since we don't
use long doubles (which is what requires 16-byte alignment), we should
be fine.

Sergey



reply via email to

[Prev in Thread] Current Thread [Next in Thread]