LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Arnd Bergmann <arnd@arndb.de>
Cc: y2038 Mailman List <y2038@lists.linaro.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	GNU C Library <libc-alpha@sourceware.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Deepa Dinamani <deepa.kernel@gmail.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Albert ARIBAUD <albert.aribaud@3adev.fr>,
	linux-s390 <linux-s390@vger.kernel.org>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	"the arch\/x86 maintainers" <x86@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	"open list\:RALINK MIPS ARCHITECTURE" <linux-mips@linux-mips.org>,
	James Hogan <jhogan@kernel.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	sparclinux <sparclinux@vger.kernel.org>
Subject: Re: [PATCH v3 01/17] y2038: asm-generic: Extend sysvipc data structures
Date: Thu, 19 Apr 2018 17:12:46 -0500	[thread overview]
Message-ID: <87k1t2n8v5.fsf@xmission.com> (raw)
In-Reply-To: <CAK8P3a2KR+0ZE5jHSmO6pSuiRPH83p75KetuQuHL1atChcTJGA@mail.gmail.com> (Arnd Bergmann's message of "Thu, 19 Apr 2018 23:24:36 +0200")

Arnd Bergmann <arnd@arndb.de> writes:

> On Thu, Apr 19, 2018 at 5:20 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Thu, Apr 19, 2018 at 4:59 PM, Eric W. Biederman <ebiederm@xmission.com> wrote:
>>> I suspect you want to use __kernel_ulong_t here instead of a raw
>>> unsigned long.  If nothing else it seems inconsistent to use typedefs
>>> in one half of the structure and no typedefs in the other half.
>>
>> Good catch, there is definitely something wrong here, but I think using
>> __kernel_ulong_t for all members would also be wrong, as that
>> still changes the layout on x32, which effectively is
>>
>> struct msqid64_ds {
>>      ipc64_perm msg_perm;
>>      u64 msg_stime;
>>      u32 __unused1;
>>      /* 32 bit implict padding */
>>      u64 msg_rtime;
>>      u32 __unused2;
>>      /* 32 bit implict padding */
>>      u64 msg_ctime;
>>      u32 __unused3;
>>      /* 32 bit implict padding */
>>      __kernel_pid_t          shm_cpid;       /* pid of creator */
>>      __kernel_pid_t          shm_lpid;       /* pid of last operator */
>>      ....
>> };
>>
>> The choices here would be to either use a mix of
>> __kernel_ulong_t and unsigned long, or taking the x32
>> version back into arch/x86/include/uapi/asm/ so the
>> generic version at least makes some sense.
>>
>> I can't use __kernel_time_t for the lower half on 32-bit
>> since it really should be unsigned.
>
> After thinking about it some more, I conclude that the structure is simply
> incorrect on x32: The __kernel_ulong_t usage was introduced in 2013
> in commit b9cd5ca22d67 ("uapi: Use __kernel_ulong_t in struct
> msqid64_ds") and apparently was correct initially as __BITS_PER_LONG
> evaluated to 64, but it broke with commit f4b4aae18288 ("x86/headers/uapi:
> Fix __BITS_PER_LONG value for x32 builds") that changed the value
> of __BITS_PER_LONG and introduced the extra padding in 2015.
>
> The same change apparently also broke a lot of other definitions, e.g.
>
> $ echo "#include <linux/types.h>" | gcc -mx32 -E -xc - | grep -A3
> __kernel_size_t
> typedef unsigned int __kernel_size_t;
> typedef int __kernel_ssize_t;
> typedef int __kernel_ptrdiff_t;
>
> Those used to be defined as 'unsigned long long' and 'long long'
> respectively, so now all kernel interfaces using those on x32
> became incompatible!

That seems like a real mess.

Is this just for the uapi header as seen by userspace?  I expect we are
using the a normal kernel interface with 64bit longs and 64bit pointers
when we build the kernel.

If this is just a header as seen from userspace mess it seems
unfortunate but fixable.

Eric

  reply	other threads:[~2018-04-19 22:14 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-19 14:37 [PATCH v3 00/17] y2038: Convert IPC syscalls Arnd Bergmann
2018-04-19 14:37 ` [PATCH v3 01/17] y2038: asm-generic: Extend sysvipc data structures Arnd Bergmann
2018-04-19 14:59   ` Eric W. Biederman
2018-04-19 15:20     ` Arnd Bergmann
2018-04-19 21:24       ` Arnd Bergmann
2018-04-19 22:12         ` Eric W. Biederman [this message]
2018-04-20  8:54           ` Arnd Bergmann
2018-04-20 13:03             ` [PATCH] x86: ipc: fix x32 version of shmid64_ds and msqid64_ds Arnd Bergmann
2018-04-20 13:53               ` Jeffrey Walton
2018-04-20 14:38                 ` Arnd Bergmann
2018-04-22 12:38                   ` H.J. Lu
2018-04-22 20:17                     ` Arnd Bergmann
2018-04-19 15:30   ` [PATCH v3 01/17] y2038: asm-generic: Extend sysvipc data structures Zack Weinberg
2018-04-19 15:51     ` Arnd Bergmann
2018-04-19 14:37 ` [PATCH v3 02/17] y2038: alpha: Remove unneeded ipc uapi header files Arnd Bergmann
2018-04-19 14:37 ` [PATCH v3 03/17] y2038: ia64: " Arnd Bergmann
2018-04-19 14:37 ` [PATCH v3 04/17] y2038: s390: " Arnd Bergmann
2018-04-20  7:54   ` Heiko Carstens
2018-04-20  7:58     ` Arnd Bergmann
2018-04-19 14:37 ` [PATCH v3 05/17] y2038: arm64: Extend sysvipc compat data structures Arnd Bergmann
2018-04-19 14:37 ` [PATCH v3 06/17] y2038: mips: Extend sysvipc " Arnd Bergmann
2018-04-19 14:37 ` [PATCH v3 07/17] y2038: x86: " Arnd Bergmann
2018-04-19 14:37 ` [PATCH v3 08/17] y2038: parisc: " Arnd Bergmann
2018-04-19 14:37 ` [PATCH v3 09/17] y2038: sparc: " Arnd Bergmann
2018-04-19 14:37 ` [PATCH v3 10/17] y2038: powerpc: " Arnd Bergmann
2018-04-19 14:37 ` [PATCH v3 11/17] y2038: xtensa: " Arnd Bergmann
2018-04-19 14:37 ` [PATCH v3 12/17] y2038: ipc: Use ktime_get_real_seconds consistently Arnd Bergmann
2018-04-19 14:37 ` [PATCH v3 13/17] y2038: ipc: Report long times to user space Arnd Bergmann
2018-04-19 14:37 ` [PATCH v3 14/17] y2038: ipc: Use __kernel_timespec Arnd Bergmann
2018-04-19 14:37 ` [PATCH v3 15/17] y2038: ipc: Enable COMPAT_32BIT_TIME Arnd Bergmann
2018-04-19 14:37 ` [PATCH v3 16/17] y2038: ipc: Redirect ipc(SEMTIMEDOP, ...) to compat_ksys_semtimedop Arnd Bergmann
2018-04-19 14:37 ` [PATCH v3 17/17] y2038: compat: Move common compat types to asm-generic/compat.h Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k1t2n8v5.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=albert.aribaud@3adev.fr \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=deepa.kernel@gmail.com \
    --cc=jhogan@kernel.org \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=ralf@linux-mips.org \
    --cc=schwidefsky@de.ibm.com \
    --cc=sparclinux@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=viro@zeniv.linux.org.uk \
    --cc=will.deacon@arm.com \
    --cc=x86@kernel.org \
    --cc=y2038@lists.linaro.org \
    --subject='Re: [PATCH v3 01/17] y2038: asm-generic: Extend sysvipc data structures' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).