LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Zack Weinberg <zackw@panix.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: y2038@lists.linaro.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-api@vger.kernel.org,
	GNU C Library <libc-alpha@sourceware.org>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: [PATCH v3 01/17] y2038: asm-generic: Extend sysvipc data structures
Date: Thu, 19 Apr 2018 11:30:34 -0400	[thread overview]
Message-ID: <CAKCAbMiaX31mpfEMRQrQbPO+kTfowA6=_KhBSs56=zZ1s0aXhw@mail.gmail.com> (raw)
In-Reply-To: <20180419143737.606138-2-arnd@arndb.de>

On Thu, Apr 19, 2018 at 10:37 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> Most architectures now use the asm-generic copy of the sysvipc data
> structures (msqid64_ds, semid64_ds, shmid64_ds), which use 32-bit
> __kernel_time_t on 32-bit architectures but have padding behind them to
> allow extending the type to 64-bit.
>
> Unfortunately, that fails on all big-endian architectures, which have the
> padding on the wrong side. As so many of them get it wrong, we decided to
> not bother even trying to fix it up when we introduced the asm-generic
> copy. Instead we always use the padding word now to provide the upper
> 32 bits of the seconds value, regardless of the endianess.
>
> A libc implementation on a typical big-endian system can deal with
> this by providing its own copy of the structure definition to user
> space, and swapping the two 32-bit words before returning from the
> semctl/shmctl/msgctl system calls.

This seems generally like a sound approach, but I need to ask whether
any of the structures involved can ever appear in a sendmsg() control
message (that is, in the data pointed to by msg_control), or an
AF_NETLINK message, or any other situation where the kernel
communicates a structured message of arbitrary size to user space or
vice versa.  libc can't munge those messages, because new message
types can be added faster than libc can keep up with them, and because
I/O primitives like sendmsg() generally aren't allowed to allocate
arbitrarily-large scratch buffers.

zw

  parent reply	other threads:[~2018-04-19 15:46 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
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   ` Zack Weinberg [this message]
2018-04-19 15:51     ` [PATCH v3 01/17] y2038: asm-generic: Extend sysvipc data structures 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='CAKCAbMiaX31mpfEMRQrQbPO+kTfowA6=_KhBSs56=zZ1s0aXhw@mail.gmail.com' \
    --to=zackw@panix.com \
    --cc=arnd@arndb.de \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=schwidefsky@de.ibm.com \
    --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).