[PATCH] linux-user: Fix msqid_ds struct wrt 32-bit big endian architectures

[PATCH] linux-user: Fix msqid_ds struct wrt 32-bit big endian architectures

[Helge Deller]

From: Helge Deller <deller@gmx.de>

Make sure that the time entries (msg_stime, msg_rtime and msg_ctime)
are defined as 64-bit time_t values, since the userspace may access
the whole 64-bit value. By this change we fix the word ordering for
32-bit big endian architectures as well.

This fixes the msgctl01 LTP testcase on hppa32.

Signed-off-by: Helge Deller <deller@gmx.de>
---
 linux-user/syscall.c | 30 ++++++++++++------------------
 1 file changed, 12 insertions(+), 18 deletions(-)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 740142825d..c93b770ced 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -4216,21 +4216,15 @@ static inline abi_long do_semtimedop(int semid,
 }
 #endif
 
+#define target_time64_t         abi_ullong
+#define target_swap_time64(x)   tswap64(x)
+
 struct target_msqid_ds
 {
     struct target_ipc_perm msg_perm;
-    abi_ulong msg_stime;
-#if TARGET_ABI_BITS == 32
-    abi_ulong __unused1;
-#endif
-    abi_ulong msg_rtime;
-#if TARGET_ABI_BITS == 32
-    abi_ulong __unused2;
-#endif
-    abi_ulong msg_ctime;
-#if TARGET_ABI_BITS == 32
-    abi_ulong __unused3;
-#endif
+    target_time64_t msg_stime;
+    target_time64_t msg_rtime;
+    target_time64_t msg_ctime;
     abi_ulong __msg_cbytes;
     abi_ulong msg_qnum;
     abi_ulong msg_qbytes;
@@ -4249,9 +4243,9 @@ static inline abi_long target_to_host_msqid_ds(struct msqid_ds *host_md,
         return -TARGET_EFAULT;
     if (target_to_host_ipc_perm(&(host_md->msg_perm),target_addr))
         return -TARGET_EFAULT;
-    host_md->msg_stime = tswapal(target_md->msg_stime);
-    host_md->msg_rtime = tswapal(target_md->msg_rtime);
-    host_md->msg_ctime = tswapal(target_md->msg_ctime);
+    host_md->msg_stime = target_swap_time64(target_md->msg_stime);
+    host_md->msg_rtime = target_swap_time64(target_md->msg_rtime);
+    host_md->msg_ctime = target_swap_time64(target_md->msg_ctime);
     host_md->__msg_cbytes = tswapal(target_md->__msg_cbytes);
     host_md->msg_qnum = tswapal(target_md->msg_qnum);
     host_md->msg_qbytes = tswapal(target_md->msg_qbytes);
@@ -4270,9 +4264,9 @@ static inline abi_long host_to_target_msqid_ds(abi_ulong target_addr,
         return -TARGET_EFAULT;
     if (host_to_target_ipc_perm(target_addr,&(host_md->msg_perm)))
         return -TARGET_EFAULT;
-    target_md->msg_stime = tswapal(host_md->msg_stime);
-    target_md->msg_rtime = tswapal(host_md->msg_rtime);
-    target_md->msg_ctime = tswapal(host_md->msg_ctime);
+    target_md->msg_stime = target_swap_time64(host_md->msg_stime);
+    target_md->msg_rtime = target_swap_time64(host_md->msg_rtime);
+    target_md->msg_ctime = target_swap_time64(host_md->msg_ctime);
     target_md->__msg_cbytes = tswapal(host_md->__msg_cbytes);
     target_md->msg_qnum = tswapal(host_md->msg_qnum);
     target_md->msg_qbytes = tswapal(host_md->msg_qbytes);
-- 
2.54.0

Re: [PATCH] linux-user: Fix msqid_ds struct wrt 32-bit big endian architectures

[Peter Maydell]

On Tue, 28 Jul 2026 at 20:32, Helge Deller <deller@kernel.org> wrote:
>
> From: Helge Deller <deller@gmx.de>
>
> Make sure that the time entries (msg_stime, msg_rtime and msg_ctime)
> are defined as 64-bit time_t values, since the userspace may access
> the whole 64-bit value. By this change we fix the word ordering for
> 32-bit big endian architectures as well.
>
> This fixes the msgctl01 LTP testcase on hppa32.
>
> Signed-off-by: Helge Deller <deller@gmx.de>
> ---
>  linux-user/syscall.c | 30 ++++++++++++------------------
>  1 file changed, 12 insertions(+), 18 deletions(-)
>
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index 740142825d..c93b770ced 100644
> --- a/linux-user/syscall.c
> +++ b/linux-user/syscall.c
> @@ -4216,21 +4216,15 @@ static inline abi_long do_semtimedop(int semid,
>  }
>  #endif

I see this has already gone into git, but some late review
comments. I suspect this is mostly me being confused rather
than actual problems.

>
> +#define target_time64_t         abi_ullong
> +#define target_swap_time64(x)   tswap64(x)
> +
>  struct target_msqid_ds

Is this the kernel's "struct msqid_ds" (which it calls "Obsolete, used
only for backwards compatibility and libc5 compiles") or its msqid64_ds?
The layout matches msqid64_ds, which makes our struct a bit
confusingly named.

>  {
>      struct target_ipc_perm msg_perm;
> -    abi_ulong msg_stime;
> -#if TARGET_ABI_BITS == 32
> -    abi_ulong __unused1;
> -#endif
> -    abi_ulong msg_rtime;
> -#if TARGET_ABI_BITS == 32
> -    abi_ulong __unused2;
> -#endif
> -    abi_ulong msg_ctime;
> -#if TARGET_ABI_BITS == 32
> -    abi_ulong __unused3;
> -#endif
> +    target_time64_t msg_stime;
> +    target_time64_t msg_rtime;
> +    target_time64_t msg_ctime;

Assuming msqid64_ds, the kernel version of this struct has a comment:
 * 64 bit architectures use a 64-bit long time field here, while
 * 32 bit architectures have a pair of unsigned long values.
 * On big-endian systems, the lower half is in the wrong place.

That would make tswap64() not the right swap for 32-bit big
endian guests.

thanks
-- PMM

Re: [PATCH] linux-user: Fix msqid_ds struct wrt 32-bit big endian architectures

[Helge Deller]

Hello Peter,

On 7/31/26 20:05, Peter Maydell wrote:
> On Tue, 28 Jul 2026 at 20:32, Helge Deller <deller@kernel.org> wrote:
>>
>> From: Helge Deller <deller@gmx.de>
>>
>> Make sure that the time entries (msg_stime, msg_rtime and msg_ctime)
>> are defined as 64-bit time_t values, since the userspace may access
>> the whole 64-bit value. By this change we fix the word ordering for
>> 32-bit big endian architectures as well.
>>
>> This fixes the msgctl01 LTP testcase on hppa32.
>>
>> Signed-off-by: Helge Deller <deller@gmx.de>
>> ---
>>   linux-user/syscall.c | 30 ++++++++++++------------------
>>   1 file changed, 12 insertions(+), 18 deletions(-)
>>
>> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
>> index 740142825d..c93b770ced 100644
>> --- a/linux-user/syscall.c
>> +++ b/linux-user/syscall.c
>> @@ -4216,21 +4216,15 @@ static inline abi_long do_semtimedop(int semid,
>>   }
>>   #endif
> 
> I see this has already gone into git, but some late review
> comments. I suspect this is mostly me being confused rather
> than actual problems.
> 
>>
>> +#define target_time64_t         abi_ullong
>> +#define target_swap_time64(x)   tswap64(x)
>> +
>>   struct target_msqid_ds
> 
> Is this the kernel's "struct msqid_ds" (which it calls "Obsolete, used
> only for backwards compatibility and libc5 compiles") or its msqid64_ds?

Yes, it's msqid64_ds.

> The layout matches msqid64_ds, which makes our struct a bit
> confusingly named.

True.
In a follow-up patch this better should be renamed to target_msqid64_ds.

>>   {
>>       struct target_ipc_perm msg_perm;
>> -    abi_ulong msg_stime;
>> -#if TARGET_ABI_BITS == 32
>> -    abi_ulong __unused1;
>> -#endif
>> -    abi_ulong msg_rtime;
>> -#if TARGET_ABI_BITS == 32
>> -    abi_ulong __unused2;
>> -#endif
>> -    abi_ulong msg_ctime;
>> -#if TARGET_ABI_BITS == 32
>> -    abi_ulong __unused3;
>> -#endif
>> +    target_time64_t msg_stime;
>> +    target_time64_t msg_rtime;
>> +    target_time64_t msg_ctime;
> 
> Assuming msqid64_ds, the kernel version of this struct has a comment:
>   * 64 bit architectures use a 64-bit long time field here, while
>   * 32 bit architectures have a pair of unsigned long values.
>   * On big-endian systems, the lower half is in the wrong place.

Those comments are from the generic header:
include/uapi/asm-generic/msgbuf.h
and I think the last sentence about big-endian systems is wrong, as
most platforms provide an own architecture-specific header file, e.g:
arch/xtensa/include/uapi/asm/msgbuf.h
and the big-endian platforms seem to have their high-word first.

> That would make tswap64() not the right swap for 32-bit big
> endian guests.
  
I did my testing on the 32-bit hppa/parisc platform, and with my patch
the results in qemu were correct and were the same as on physical machines.

I just tried in a 32-bit powerpc chroot and the msgctl01 now succeeds there as well.
So, I think my patch is generally ok.

Helge

Re: [PATCH] linux-user: Fix msqid_ds struct wrt 32-bit big endian architectures

[Peter Maydell]

On Fri, 31 Jul 2026 at 20:36, Helge Deller <deller@gmx.de> wrote:
>
> Hello Peter,
>
> On 7/31/26 20:05, Peter Maydell wrote:
> > On Tue, 28 Jul 2026 at 20:32, Helge Deller <deller@kernel.org> wrote:
> >>
> >> From: Helge Deller <deller@gmx.de>
> >>
> >> Make sure that the time entries (msg_stime, msg_rtime and msg_ctime)
> >> are defined as 64-bit time_t values, since the userspace may access
> >> the whole 64-bit value. By this change we fix the word ordering for
> >> 32-bit big endian architectures as well.
> >>
> >> This fixes the msgctl01 LTP testcase on hppa32.
> >>
> >> Signed-off-by: Helge Deller <deller@gmx.de>
> >> ---
> >>   linux-user/syscall.c | 30 ++++++++++++------------------
> >>   1 file changed, 12 insertions(+), 18 deletions(-)
> >>
> >> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> >> index 740142825d..c93b770ced 100644
> >> --- a/linux-user/syscall.c
> >> +++ b/linux-user/syscall.c
> >> @@ -4216,21 +4216,15 @@ static inline abi_long do_semtimedop(int semid,
> >>   }
> >>   #endif
> >
> > I see this has already gone into git, but some late review
> > comments. I suspect this is mostly me being confused rather
> > than actual problems.
> >
> >>
> >> +#define target_time64_t         abi_ullong
> >> +#define target_swap_time64(x)   tswap64(x)
> >> +
> >>   struct target_msqid_ds
> >
> > Is this the kernel's "struct msqid_ds" (which it calls "Obsolete, used
> > only for backwards compatibility and libc5 compiles") or its msqid64_ds?
>
> Yes, it's msqid64_ds.
>
> > The layout matches msqid64_ds, which makes our struct a bit
> > confusingly named.
>
> True.
> In a follow-up patch this better should be renamed to target_msqid64_ds.
>
> >>   {
> >>       struct target_ipc_perm msg_perm;
> >> -    abi_ulong msg_stime;
> >> -#if TARGET_ABI_BITS == 32
> >> -    abi_ulong __unused1;
> >> -#endif
> >> -    abi_ulong msg_rtime;
> >> -#if TARGET_ABI_BITS == 32
> >> -    abi_ulong __unused2;
> >> -#endif
> >> -    abi_ulong msg_ctime;
> >> -#if TARGET_ABI_BITS == 32
> >> -    abi_ulong __unused3;
> >> -#endif
> >> +    target_time64_t msg_stime;
> >> +    target_time64_t msg_rtime;
> >> +    target_time64_t msg_ctime;
> >
> > Assuming msqid64_ds, the kernel version of this struct has a comment:
> >   * 64 bit architectures use a 64-bit long time field here, while
> >   * 32 bit architectures have a pair of unsigned long values.
> >   * On big-endian systems, the lower half is in the wrong place.
>
> Those comments are from the generic header:
> include/uapi/asm-generic/msgbuf.h
> and I think the last sentence about big-endian systems is wrong, as
> most platforms provide an own architecture-specific header file, e.g:
> arch/xtensa/include/uapi/asm/msgbuf.h
> and the big-endian platforms seem to have their high-word first.

The comment is correct for any bigendian 32-bit system that
uses the kernel's asm-generic structure. Maybe there just aren't
any of those that we care about?

> > That would make tswap64() not the right swap for 32-bit big
> > endian guests.
>
> I did my testing on the 32-bit hppa/parisc platform, and with my patch
> the results in qemu were correct and were the same as on physical machines.
>
> I just tried in a 32-bit powerpc chroot and the msgctl01 now succeeds there as well.
> So, I think my patch is generally ok.

Yeah, 32-bit powerpc also provides its own structure definition.

I think it's worth having a comment about this, at least, because
otherwise the obvious assumption is that our struct which has
no target-specific ifdefs is supposed to match the kernel's
asm-generic struct.

We could alternatively follow the kernel more closely in having our
generic struct match the kernel's and then having the archs which
have custom versions override that, but that would be a bunch of
extra work to get to the same place in the end.

thanks
-- PMM

Re: [PATCH] linux-user: Fix msqid_ds struct wrt 32-bit big endian architectures

[Helge Deller]

On 8/1/26 14:11, Peter Maydell wrote:
> On Fri, 31 Jul 2026 at 20:36, Helge Deller <deller@gmx.de> wrote:
>>
>> Hello Peter,
>>
>> On 7/31/26 20:05, Peter Maydell wrote:
>>> On Tue, 28 Jul 2026 at 20:32, Helge Deller <deller@kernel.org> wrote:
>>>>
>>>> From: Helge Deller <deller@gmx.de>
>>>>
>>>> Make sure that the time entries (msg_stime, msg_rtime and msg_ctime)
>>>> are defined as 64-bit time_t values, since the userspace may access
>>>> the whole 64-bit value. By this change we fix the word ordering for
>>>> 32-bit big endian architectures as well.
>>>>
>>>> This fixes the msgctl01 LTP testcase on hppa32.
>>>>
>>>> Signed-off-by: Helge Deller <deller@gmx.de>
>>>> ---
>>>>    linux-user/syscall.c | 30 ++++++++++++------------------
>>>>    1 file changed, 12 insertions(+), 18 deletions(-)
>>>>
>>>> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
>>>> index 740142825d..c93b770ced 100644
>>>> --- a/linux-user/syscall.c
>>>> +++ b/linux-user/syscall.c
>>>> @@ -4216,21 +4216,15 @@ static inline abi_long do_semtimedop(int semid,
>>>>    }
>>>>    #endif
>>>
>>> I see this has already gone into git, but some late review
>>> comments. I suspect this is mostly me being confused rather
>>> than actual problems.
>>>
>>>>
>>>> +#define target_time64_t         abi_ullong
>>>> +#define target_swap_time64(x)   tswap64(x)
>>>> +
>>>>    struct target_msqid_ds
>>>
>>> Is this the kernel's "struct msqid_ds" (which it calls "Obsolete, used
>>> only for backwards compatibility and libc5 compiles") or its msqid64_ds?
>>
>> Yes, it's msqid64_ds.
>>
>>> The layout matches msqid64_ds, which makes our struct a bit
>>> confusingly named.
>>
>> True.
>> In a follow-up patch this better should be renamed to target_msqid64_ds.
>>
>>>>    {
>>>>        struct target_ipc_perm msg_perm;
>>>> -    abi_ulong msg_stime;
>>>> -#if TARGET_ABI_BITS == 32
>>>> -    abi_ulong __unused1;
>>>> -#endif
>>>> -    abi_ulong msg_rtime;
>>>> -#if TARGET_ABI_BITS == 32
>>>> -    abi_ulong __unused2;
>>>> -#endif
>>>> -    abi_ulong msg_ctime;
>>>> -#if TARGET_ABI_BITS == 32
>>>> -    abi_ulong __unused3;
>>>> -#endif
>>>> +    target_time64_t msg_stime;
>>>> +    target_time64_t msg_rtime;
>>>> +    target_time64_t msg_ctime;
>>>
>>> Assuming msqid64_ds, the kernel version of this struct has a comment:
>>>    * 64 bit architectures use a 64-bit long time field here, while
>>>    * 32 bit architectures have a pair of unsigned long values.
>>>    * On big-endian systems, the lower half is in the wrong place.
>>
>> Those comments are from the generic header:
>> include/uapi/asm-generic/msgbuf.h
>> and I think the last sentence about big-endian systems is wrong, as
>> most platforms provide an own architecture-specific header file, e.g:
>> arch/xtensa/include/uapi/asm/msgbuf.h
>> and the big-endian platforms seem to have their high-word first.
> 
> The comment is correct for any bigendian 32-bit system that
> uses the kernel's asm-generic structure. Maybe there just aren't
> any of those that we care about?

m68k could be a problem.
The other big-arches seem to be handled correctly by the kernel:
arch/sparc/include/uapi/asm/msgbuf.h:struct msqid64_ds {
arch/parisc/include/uapi/asm/msgbuf.h:struct msqid64_ds {
arch/xtensa/include/uapi/asm/msgbuf.h:struct msqid64_ds {
arch/x86/include/uapi/asm/msgbuf.h:struct msqid64_ds {
arch/powerpc/include/uapi/asm/msgbuf.h:struct msqid64_ds {
arch/mips/include/uapi/asm/msgbuf.h:struct msqid64_ds {
arch/mips/include/uapi/asm/msgbuf.h:struct msqid64_ds {
arch/mips/include/uapi/asm/msgbuf.h:struct msqid64_ds {
  
>>> That would make tswap64() not the right swap for 32-bit big
>>> endian guests.
>>
>> I did my testing on the 32-bit hppa/parisc platform, and with my patch
>> the results in qemu were correct and were the same as on physical machines.
>>
>> I just tried in a 32-bit powerpc chroot and the msgctl01 now succeeds there as well.
>> So, I think my patch is generally ok.
> 
> Yeah, 32-bit powerpc also provides its own structure definition.
> 
> I think it's worth having a comment about this, at least, because
> otherwise the obvious assumption is that our struct which has
> no target-specific ifdefs is supposed to match the kernel's
> asm-generic struct.

Yes, I will the testing on m68k, afterwards I can come up with a proposal.
Maybe it makes sense to modify the kernel comment too....

> We could alternatively follow the kernel more closely in having our
> generic struct match the kernel's and then having the archs which
> have custom versions override that, but that would be a bunch of
> extra work to get to the same place in the end.
Let me do the testing on m68k. If the tests fail with the current code,
we need to add custom versions anyway.

Helge

Re: [PATCH] linux-user: Fix msqid_ds struct wrt 32-bit big endian architectures

[Helge Deller]

(Adding Geert as kernel m68k maintainer)

On 8/1/26 22:58, Helge Deller wrote:
> On 8/1/26 14:11, Peter Maydell wrote:
>> On Fri, 31 Jul 2026 at 20:36, Helge Deller <deller@gmx.de> wrote:
>>>
>>> Hello Peter,
>>>
>>> On 7/31/26 20:05, Peter Maydell wrote:
>>>> On Tue, 28 Jul 2026 at 20:32, Helge Deller <deller@kernel.org> wrote:
>>>>>
>>>>> From: Helge Deller <deller@gmx.de>
>>>>>
>>>>> Make sure that the time entries (msg_stime, msg_rtime and msg_ctime)
>>>>> are defined as 64-bit time_t values, since the userspace may access
>>>>> the whole 64-bit value. By this change we fix the word ordering for
>>>>> 32-bit big endian architectures as well.
>>>>>
>>>>> This fixes the msgctl01 LTP testcase on hppa32.
>>>>>
>>>>> Signed-off-by: Helge Deller <deller@gmx.de>
>>>>> ---
>>>>>    linux-user/syscall.c | 30 ++++++++++++------------------
>>>>>    1 file changed, 12 insertions(+), 18 deletions(-)
>>>>>
>>>>> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
>>>>> index 740142825d..c93b770ced 100644
>>>>> --- a/linux-user/syscall.c
>>>>> +++ b/linux-user/syscall.c
>>>>> @@ -4216,21 +4216,15 @@ static inline abi_long do_semtimedop(int semid,
>>>>>    }
>>>>>    #endif
>>>>
>>>> I see this has already gone into git, but some late review
>>>> comments. I suspect this is mostly me being confused rather
>>>> than actual problems.
>>>>
>>>>>
>>>>> +#define target_time64_t         abi_ullong
>>>>> +#define target_swap_time64(x)   tswap64(x)
>>>>> +
>>>>>    struct target_msqid_ds
>>>>
>>>> Is this the kernel's "struct msqid_ds" (which it calls "Obsolete, used
>>>> only for backwards compatibility and libc5 compiles") or its msqid64_ds?
>>>
>>> Yes, it's msqid64_ds.
>>>
>>>> The layout matches msqid64_ds, which makes our struct a bit
>>>> confusingly named.
>>>
>>> True.
>>> In a follow-up patch this better should be renamed to target_msqid64_ds.
>>>
>>>>>    {
>>>>>        struct target_ipc_perm msg_perm;
>>>>> -    abi_ulong msg_stime;
>>>>> -#if TARGET_ABI_BITS == 32
>>>>> -    abi_ulong __unused1;
>>>>> -#endif
>>>>> -    abi_ulong msg_rtime;
>>>>> -#if TARGET_ABI_BITS == 32
>>>>> -    abi_ulong __unused2;
>>>>> -#endif
>>>>> -    abi_ulong msg_ctime;
>>>>> -#if TARGET_ABI_BITS == 32
>>>>> -    abi_ulong __unused3;
>>>>> -#endif
>>>>> +    target_time64_t msg_stime;
>>>>> +    target_time64_t msg_rtime;
>>>>> +    target_time64_t msg_ctime;
>>>>
>>>> Assuming msqid64_ds, the kernel version of this struct has a comment:
>>>>    * 64 bit architectures use a 64-bit long time field here, while
>>>>    * 32 bit architectures have a pair of unsigned long values.
>>>>    * On big-endian systems, the lower half is in the wrong place.
>>>
>>> Those comments are from the generic header:
>>> include/uapi/asm-generic/msgbuf.h
>>> and I think the last sentence about big-endian systems is wrong, as
>>> most platforms provide an own architecture-specific header file, e.g:
>>> arch/xtensa/include/uapi/asm/msgbuf.h
>>> and the big-endian platforms seem to have their high-word first.
>>
>> The comment is correct for any bigendian 32-bit system that
>> uses the kernel's asm-generic structure. Maybe there just aren't
>> any of those that we care about?
> 
> m68k could be a problem.
> The other big-arches seem to be handled correctly by the kernel:
> arch/sparc/include/uapi/asm/msgbuf.h:struct msqid64_ds {
> arch/parisc/include/uapi/asm/msgbuf.h:struct msqid64_ds {
> arch/xtensa/include/uapi/asm/msgbuf.h:struct msqid64_ds {
> arch/x86/include/uapi/asm/msgbuf.h:struct msqid64_ds {
> arch/powerpc/include/uapi/asm/msgbuf.h:struct msqid64_ds {
> arch/mips/include/uapi/asm/msgbuf.h:struct msqid64_ds {
> arch/mips/include/uapi/asm/msgbuf.h:struct msqid64_ds {
> arch/mips/include/uapi/asm/msgbuf.h:struct msqid64_ds {
> 
>>>> That would make tswap64() not the right swap for 32-bit big
>>>> endian guests.
>>>
>>> I did my testing on the 32-bit hppa/parisc platform, and with my patch
>>> the results in qemu were correct and were the same as on physical machines.
>>>
>>> I just tried in a 32-bit powerpc chroot and the msgctl01 now succeeds there as well.
>>> So, I think my patch is generally ok.
>>
>> Yeah, 32-bit powerpc also provides its own structure definition.
>>
>> I think it's worth having a comment about this, at least, because
>> otherwise the obvious assumption is that our struct which has
>> no target-specific ifdefs is supposed to match the kernel's
>> asm-generic struct.
> 
> Yes, I will the testing on m68k, afterwards I can come up with a proposal.
> Maybe it makes sense to modify the kernel comment too....


The msgctl01 testcase from LTP gives this preprocessed code on m68k:
...
# 27 "/usr/include/m68k-linux-gnu/bits/types/struct_msqid_ds.h" 3 4
struct msqid_ds
{

# 1 "/usr/include/m68k-linux-gnu/bits/types/struct_msqid64_ds_helper.h" 1 3 4
# 20 "/usr/include/m68k-linux-gnu/bits/types/struct_msqid64_ds_helper.h" 3 4
   struct ipc_perm msg_perm;
   __time64_t msg_stime;
   __time64_t msg_rtime;
   __time64_t msg_ctime;
   __syscall_ulong_t __msg_cbytes;
   msgqnum_t msg_qnum;
   msglen_t msg_qbytes;
   __pid_t msg_lspid;
   __pid_t msg_lrpid;
   unsigned long int __glibc_reserved4;
   unsigned long int __glibc_reserved5;
# 31 "/usr/include/m68k-linux-gnu/bits/types/struct_msqid_ds.h" 2 3 4
# 53 "/usr/include/m68k-linux-gnu/bits/types/struct_msqid_ds.h" 3 4
};

but the testcase fails with:
msgctl01.c:53: TFAIL: msg_ctime = 6a6e65d900000000, expected 6a6e65d9

So, for m68k either the glibc or the kernel is wrong.
At least they don't agree with each other.

I think it would be beneficial, if the m68k kernel would follow m68k's
glibc implementation of msqid64_ds.

Helge

Re: [PATCH] linux-user: Fix msqid_ds struct wrt 32-bit big endian architectures

[Geert Uytterhoeven]

CC linux-m68k

On Sat, 1 Aug 2026 at 23:39, Helge Deller <deller@gmx.de> wrote:
>
> (Adding Geert as kernel m68k maintainer)
>
> On 8/1/26 22:58, Helge Deller wrote:
> > On 8/1/26 14:11, Peter Maydell wrote:
> >> On Fri, 31 Jul 2026 at 20:36, Helge Deller <deller@gmx.de> wrote:
> >>>
> >>> Hello Peter,
> >>>
> >>> On 7/31/26 20:05, Peter Maydell wrote:
> >>>> On Tue, 28 Jul 2026 at 20:32, Helge Deller <deller@kernel.org> wrote:
> >>>>>
> >>>>> From: Helge Deller <deller@gmx.de>
> >>>>>
> >>>>> Make sure that the time entries (msg_stime, msg_rtime and msg_ctime)
> >>>>> are defined as 64-bit time_t values, since the userspace may access
> >>>>> the whole 64-bit value. By this change we fix the word ordering for
> >>>>> 32-bit big endian architectures as well.
> >>>>>
> >>>>> This fixes the msgctl01 LTP testcase on hppa32.
> >>>>>
> >>>>> Signed-off-by: Helge Deller <deller@gmx.de>
> >>>>> ---
> >>>>>    linux-user/syscall.c | 30 ++++++++++++------------------
> >>>>>    1 file changed, 12 insertions(+), 18 deletions(-)
> >>>>>
> >>>>> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> >>>>> index 740142825d..c93b770ced 100644
> >>>>> --- a/linux-user/syscall.c
> >>>>> +++ b/linux-user/syscall.c
> >>>>> @@ -4216,21 +4216,15 @@ static inline abi_long do_semtimedop(int semid,
> >>>>>    }
> >>>>>    #endif
> >>>>
> >>>> I see this has already gone into git, but some late review
> >>>> comments. I suspect this is mostly me being confused rather
> >>>> than actual problems.
> >>>>
> >>>>>
> >>>>> +#define target_time64_t         abi_ullong
> >>>>> +#define target_swap_time64(x)   tswap64(x)
> >>>>> +
> >>>>>    struct target_msqid_ds
> >>>>
> >>>> Is this the kernel's "struct msqid_ds" (which it calls "Obsolete, used
> >>>> only for backwards compatibility and libc5 compiles") or its msqid64_ds?
> >>>
> >>> Yes, it's msqid64_ds.
> >>>
> >>>> The layout matches msqid64_ds, which makes our struct a bit
> >>>> confusingly named.
> >>>
> >>> True.
> >>> In a follow-up patch this better should be renamed to target_msqid64_ds.
> >>>
> >>>>>    {
> >>>>>        struct target_ipc_perm msg_perm;
> >>>>> -    abi_ulong msg_stime;
> >>>>> -#if TARGET_ABI_BITS == 32
> >>>>> -    abi_ulong __unused1;
> >>>>> -#endif
> >>>>> -    abi_ulong msg_rtime;
> >>>>> -#if TARGET_ABI_BITS == 32
> >>>>> -    abi_ulong __unused2;
> >>>>> -#endif
> >>>>> -    abi_ulong msg_ctime;
> >>>>> -#if TARGET_ABI_BITS == 32
> >>>>> -    abi_ulong __unused3;
> >>>>> -#endif
> >>>>> +    target_time64_t msg_stime;
> >>>>> +    target_time64_t msg_rtime;
> >>>>> +    target_time64_t msg_ctime;
> >>>>
> >>>> Assuming msqid64_ds, the kernel version of this struct has a comment:
> >>>>    * 64 bit architectures use a 64-bit long time field here, while
> >>>>    * 32 bit architectures have a pair of unsigned long values.
> >>>>    * On big-endian systems, the lower half is in the wrong place.
> >>>
> >>> Those comments are from the generic header:
> >>> include/uapi/asm-generic/msgbuf.h
> >>> and I think the last sentence about big-endian systems is wrong, as
> >>> most platforms provide an own architecture-specific header file, e.g:
> >>> arch/xtensa/include/uapi/asm/msgbuf.h
> >>> and the big-endian platforms seem to have their high-word first.
> >>
> >> The comment is correct for any bigendian 32-bit system that
> >> uses the kernel's asm-generic structure. Maybe there just aren't
> >> any of those that we care about?
> >
> > m68k could be a problem.
> > The other big-arches seem to be handled correctly by the kernel:
> > arch/sparc/include/uapi/asm/msgbuf.h:struct msqid64_ds {
> > arch/parisc/include/uapi/asm/msgbuf.h:struct msqid64_ds {
> > arch/xtensa/include/uapi/asm/msgbuf.h:struct msqid64_ds {
> > arch/x86/include/uapi/asm/msgbuf.h:struct msqid64_ds {
> > arch/powerpc/include/uapi/asm/msgbuf.h:struct msqid64_ds {
> > arch/mips/include/uapi/asm/msgbuf.h:struct msqid64_ds {
> > arch/mips/include/uapi/asm/msgbuf.h:struct msqid64_ds {
> > arch/mips/include/uapi/asm/msgbuf.h:struct msqid64_ds {
> >
> >>>> That would make tswap64() not the right swap for 32-bit big
> >>>> endian guests.
> >>>
> >>> I did my testing on the 32-bit hppa/parisc platform, and with my patch
> >>> the results in qemu were correct and were the same as on physical machines.
> >>>
> >>> I just tried in a 32-bit powerpc chroot and the msgctl01 now succeeds there as well.
> >>> So, I think my patch is generally ok.
> >>
> >> Yeah, 32-bit powerpc also provides its own structure definition.
> >>
> >> I think it's worth having a comment about this, at least, because
> >> otherwise the obvious assumption is that our struct which has
> >> no target-specific ifdefs is supposed to match the kernel's
> >> asm-generic struct.
> >
> > Yes, I will the testing on m68k, afterwards I can come up with a proposal.
> > Maybe it makes sense to modify the kernel comment too....
>
>
> The msgctl01 testcase from LTP gives this preprocessed code on m68k:
> ...
> # 27 "/usr/include/m68k-linux-gnu/bits/types/struct_msqid_ds.h" 3 4
> struct msqid_ds
> {
>
> # 1 "/usr/include/m68k-linux-gnu/bits/types/struct_msqid64_ds_helper.h" 1 3 4
> # 20 "/usr/include/m68k-linux-gnu/bits/types/struct_msqid64_ds_helper.h" 3 4
>    struct ipc_perm msg_perm;
>    __time64_t msg_stime;
>    __time64_t msg_rtime;
>    __time64_t msg_ctime;
>    __syscall_ulong_t __msg_cbytes;
>    msgqnum_t msg_qnum;
>    msglen_t msg_qbytes;
>    __pid_t msg_lspid;
>    __pid_t msg_lrpid;
>    unsigned long int __glibc_reserved4;
>    unsigned long int __glibc_reserved5;
> # 31 "/usr/include/m68k-linux-gnu/bits/types/struct_msqid_ds.h" 2 3 4
> # 53 "/usr/include/m68k-linux-gnu/bits/types/struct_msqid_ds.h" 3 4
> };
>
> but the testcase fails with:
> msgctl01.c:53: TFAIL: msg_ctime = 6a6e65d900000000, expected 6a6e65d9
>
> So, for m68k either the glibc or the kernel is wrong.
> At least they don't agree with each other.
>
> I think it would be beneficial, if the m68k kernel would follow m68k's
> glibc implementation of msqid64_ds.
>
> Helge

Re: [PATCH] linux-user: Fix msqid_ds struct wrt 32-bit big endian architectures

[Andreas Schwab]

On Aug 01 2026, Helge Deller wrote:

> msgctl01.c:53: TFAIL: msg_ctime = 6a6e65d900000000, expected 6a6e65d9

If you use -D_TIME_BITS=32 with struct msqid_ds it will work, I'm sure,
even though glibc uses the same (time64) syscall.

> So, for m68k either the glibc or the kernel is wrong.

Both are wrong.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH] linux-user: Fix msqid_ds struct wrt 32-bit big endian architectures

[Andreas Schwab]

On Aug 01 2026, Helge Deller wrote:

> m68k could be a problem.
> The other big-arches seem to be handled correctly by the kernel:
> arch/sparc/include/uapi/asm/msgbuf.h:struct msqid64_ds {
> arch/parisc/include/uapi/asm/msgbuf.h:struct msqid64_ds {
> arch/xtensa/include/uapi/asm/msgbuf.h:struct msqid64_ds {
> arch/x86/include/uapi/asm/msgbuf.h:struct msqid64_ds {
> arch/powerpc/include/uapi/asm/msgbuf.h:struct msqid64_ds {
> arch/mips/include/uapi/asm/msgbuf.h:struct msqid64_ds {
> arch/mips/include/uapi/asm/msgbuf.h:struct msqid64_ds {
> arch/mips/include/uapi/asm/msgbuf.h:struct msqid64_ds {

glibc commit 9f9feb6d5d says:

    * Some older 32-bit big-endian architectures have padding before
      rather than after time fields, although the preferred generic
      approach is padding after the time fields independent of endianness.

and m68k uses the "preferred" approach.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH] linux-user: Fix msqid_ds struct wrt 32-bit big endian architectures

[Helge Deller]

* Andreas Schwab <schwab@linux-m68k.org>:
> On Aug 01 2026, Helge Deller wrote:
> 
> > m68k could be a problem.
> > The other big-arches seem to be handled correctly by the kernel:
> > arch/sparc/include/uapi/asm/msgbuf.h:struct msqid64_ds {
> > arch/parisc/include/uapi/asm/msgbuf.h:struct msqid64_ds {
> > arch/xtensa/include/uapi/asm/msgbuf.h:struct msqid64_ds {
> > arch/x86/include/uapi/asm/msgbuf.h:struct msqid64_ds {
> > arch/powerpc/include/uapi/asm/msgbuf.h:struct msqid64_ds {
> > arch/mips/include/uapi/asm/msgbuf.h:struct msqid64_ds {
> > arch/mips/include/uapi/asm/msgbuf.h:struct msqid64_ds {
> > arch/mips/include/uapi/asm/msgbuf.h:struct msqid64_ds {
> 
> glibc commit 9f9feb6d5d says:
> 
>     * Some older 32-bit big-endian architectures have padding before
>       rather than after time fields, although the preferred generic
>       approach is padding after the time fields independent of endianness.
> 
> and m68k uses the "preferred" approach.

Thanks for the info, Andreas!
The msgctl01 LTP testcase does work correctly on a physical m68k
machine for me, so glibc/kernel seems ok, esp. regarding msqid64_ds.

Regarding qemu linux-user the patch below seems to fix the LTP msgctl01
testcase in my m68k qemu chroot. Peter, do you mind reviewing the patch?

Helge
-------

From: Helge Deller <deller@gmx.de>
Date: Mon, 3 Aug 2026 22:49:46 +0200
Subject: [PATCH] linux-user: Fox msqid64_ds for 32-bit big endian m68k target

On some older 32 bit big-endian architectures (like m68k) the 64-bit time
fields of msqid64_ds is a pair of unsigned long values, where the lower
half is in the wrong place. Adjust the target_swap_time64() macro
accordingly.

Fixes: 9e3df3019d21 ("linux-user: Fix msqid_ds struct wrt 32-bit big endian architectures")
Noticed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Helge Deller <deller@gmx.de>

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index dc028686f4..1a18fea52d 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -4217,7 +4217,16 @@ static inline abi_long do_semtimedop(int semid,
 #endif
 
 #define target_time64_t         abi_ullong
-#define target_swap_time64(x)   tswap64(x)
+/*
+  * On some older 32 bit big-endian architectures (like m68k) the 64-bit time
+  * fields of msqid64_ds is a pair of unsigned long values, where the lower
+  * half is in the wrong place.
+ */
+#ifdef TARGET_M68K
+# define target_swap_time64(x)   (tswap32(x) | (((uint64_t)tswap32((x) >> 32)) << 32))
+#else
+# define target_swap_time64(x)   tswap64(x)
+#endif
 
 struct target_msqid_ds
 {

Re: [PATCH] linux-user: Fix msqid_ds struct wrt 32-bit big endian architectures

[Andreas Schwab]

On Aug 03 2026, Helge Deller wrote:

> * Andreas Schwab <schwab@linux-m68k.org>:
>> On Aug 01 2026, Helge Deller wrote:
>> 
>> > m68k could be a problem.
>> > The other big-arches seem to be handled correctly by the kernel:
>> > arch/sparc/include/uapi/asm/msgbuf.h:struct msqid64_ds {
>> > arch/parisc/include/uapi/asm/msgbuf.h:struct msqid64_ds {
>> > arch/xtensa/include/uapi/asm/msgbuf.h:struct msqid64_ds {
>> > arch/x86/include/uapi/asm/msgbuf.h:struct msqid64_ds {
>> > arch/powerpc/include/uapi/asm/msgbuf.h:struct msqid64_ds {
>> > arch/mips/include/uapi/asm/msgbuf.h:struct msqid64_ds {
>> > arch/mips/include/uapi/asm/msgbuf.h:struct msqid64_ds {
>> > arch/mips/include/uapi/asm/msgbuf.h:struct msqid64_ds {
>> 
>> glibc commit 9f9feb6d5d says:
>> 
>>     * Some older 32-bit big-endian architectures have padding before
>>       rather than after time fields, although the preferred generic
>>       approach is padding after the time fields independent of endianness.
>> 
>> and m68k uses the "preferred" approach.
>
> Thanks for the info, Andreas!
> The msgctl01 LTP testcase does work correctly on a physical m68k
> machine for me, so glibc/kernel seems ok, esp. regarding msqid64_ds.

Which glibc version did you test?  Did you test _TIME_BITS=64?  This
"preferred" approach does not really make any sense at all.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: [PATCH] linux-user: Fix msqid_ds struct wrt 32-bit big endian architectures

[Helge Deller]

On 8/3/26 23:42, Andreas Schwab wrote:
> On Aug 03 2026, Helge Deller wrote:
> 
>> * Andreas Schwab <schwab@linux-m68k.org>:
>>> On Aug 01 2026, Helge Deller wrote:
>>>
>>>> m68k could be a problem.
>>>> The other big-arches seem to be handled correctly by the kernel:
>>>> arch/sparc/include/uapi/asm/msgbuf.h:struct msqid64_ds {
>>>> arch/parisc/include/uapi/asm/msgbuf.h:struct msqid64_ds {
>>>> arch/xtensa/include/uapi/asm/msgbuf.h:struct msqid64_ds {
>>>> arch/x86/include/uapi/asm/msgbuf.h:struct msqid64_ds {
>>>> arch/powerpc/include/uapi/asm/msgbuf.h:struct msqid64_ds {
>>>> arch/mips/include/uapi/asm/msgbuf.h:struct msqid64_ds {
>>>> arch/mips/include/uapi/asm/msgbuf.h:struct msqid64_ds {
>>>> arch/mips/include/uapi/asm/msgbuf.h:struct msqid64_ds {
>>>
>>> glibc commit 9f9feb6d5d says:
>>>
>>>      * Some older 32-bit big-endian architectures have padding before
>>>        rather than after time fields, although the preferred generic
>>>        approach is padding after the time fields independent of endianness.
>>>
>>> and m68k uses the "preferred" approach.
>>
>> Thanks for the info, Andreas!
>> The msgctl01 LTP testcase does work correctly on a physical m68k
>> machine for me, so glibc/kernel seems ok, esp. regarding msqid64_ds.
> 
> Which glibc version did you test? 

(m68k-chroot)root@p100:/# cat /etc/debian_version
forky/sid

(m68k-chroot)root@p100:/# dpkg -l | grep libc6
ii  libc6:m68k                    2.42-17                   m68k         GNU C Library: Shared libraries
ii  libc6-dev:m68k                2.42-17                   m68k         GNU C Library: Development Libraries and Header Files

> Did you test _TIME_BITS=64?

Yes, because on Debian this is the default for all 32-bit architectures now
(with exception of 32-bit x86).

>  This "preferred" approach does not really make any sense at all.

Right. IMHO this "preferred" (aka padding behind 32-bit time value even on big-endian)
doesn't make any sense for big-endian. The lower 32-bit value then ends up in the upper
32-bits of a 64-bit time_t value and thus you have problems when mixing 32- and 64-bit
time_t applications.
I think m68k needs to follow the other 32-bit big-endian arches I mentioned above
and provide an own uapi/asm/msgbuf.h:struct msqid64_ds file/struct.
And this stupid "preferred" sentence in the kernel should be dropped.

Helge

Re: [PATCH] linux-user: Fix msqid_ds struct wrt 32-bit big endian architectures

[Peter Maydell]

On Tue, 4 Aug 2026 at 07:30, Helge Deller <deller@gmx.de> wrote:
>
> On 8/3/26 23:42, Andreas Schwab wrote:
> >  This "preferred" approach does not really make any sense at all.
>
> Right. IMHO this "preferred" (aka padding behind 32-bit time value even on big-endian)
> doesn't make any sense for big-endian. The lower 32-bit value then ends up in the upper
> 32-bits of a 64-bit time_t value and thus you have problems when mixing 32- and 64-bit
> time_t applications.
> I think m68k needs to follow the other 32-bit big-endian arches I mentioned above
> and provide an own uapi/asm/msgbuf.h:struct msqid64_ds file/struct.
> And this stupid "preferred" sentence in the kernel should be dropped.

If every 32-bit big-endian architecture is avoiding the asm-generic
msqid64_ds struct in order to provide its own, and they are all
exactly the same, could the asm-generic one be made to do what all the
32-bit BE archs actually want rather than something that nobody wants?

-- PMM

Re: [PATCH] linux-user: Fix msqid_ds struct wrt 32-bit big endian architectures

[Helge Deller]

On 8/7/26 15:12, Peter Maydell wrote:
> On Tue, 4 Aug 2026 at 07:30, Helge Deller <deller@gmx.de> wrote:
>>
>> On 8/3/26 23:42, Andreas Schwab wrote:
>>>   This "preferred" approach does not really make any sense at all.
>>
>> Right. IMHO this "preferred" (aka padding behind 32-bit time value even on big-endian)
>> doesn't make any sense for big-endian. The lower 32-bit value then ends up in the upper
>> 32-bits of a 64-bit time_t value and thus you have problems when mixing 32- and 64-bit
>> time_t applications.
>> I think m68k needs to follow the other 32-bit big-endian arches I mentioned above
>> and provide an own uapi/asm/msgbuf.h:struct msqid64_ds file/struct.
>> And this stupid "preferred" sentence in the kernel should be dropped.
> 
> If every 32-bit big-endian architecture is avoiding the asm-generic
> msqid64_ds struct in order to provide its own, and they are all
> exactly the same, could the asm-generic one be made to do what all the
> 32-bit BE archs actually want rather than something that nobody wants?
Yes. I fully agree.
Andreas, do you agree as well, that all 32-bit kernel architectures
should follow this path and we should drop the "preferred" thing and switch
to a native 64-bit time value?
If so, I'd willing to come up with a kernel patch...

Helge

Re: [PATCH] linux-user: Fix msqid_ds struct wrt 32-bit big endian architectures

[Andreas Schwab]

On Aug 07 2026, Helge Deller wrote:

> Andreas, do you agree as well, that all 32-bit kernel architectures
> should follow this path and we should drop the "preferred" thing and switch
> to a native 64-bit time value?

That would be an ABI break.  But on the glibc side, the m68k definition
of struct msqid_ds is broken as well, having incompatible layout beteen
_TIME_BITS=64 and _TIME_BITS=32 definitions.

> If so, I'd willing to come up with a kernel patch...

Let's see what the kernel experts recommend.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."