Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Florian Weimer <fweimer@redhat.com>
To:     Harald van Dijk <harald@gigawatt.nl>
Cc:     Andy Lutomirski <luto@kernel.org>,
        Jessica Clarke <jrtc27@jrtc27.com>,
        Rich Felker <dalias@libc.org>, linux-x86_64@vger.kernel.org,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        X86 ML <x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] x86: Fix x32 System V message queue syscalls
References: <1156938F-A9A3-4EE9-B059-2294A0B9FBFE@jrtc27.com>
        <20201012134444.1905-1-jrtc27@jrtc27.com>
        <CALCETrWKwFD7QhFQu9X_yQeVW1_yy-gEMNEtsWmQK=fNg9y68A@mail.gmail.com>
        <20201101012202.GM534@brightrain.aerifal.cx>
        <7842A462-0ADB-4EE3-B4CB-AE6DCD70CE1C@jrtc27.com>
        <20201101015013.GN534@brightrain.aerifal.cx>
        <CALCETrUuBR3Pt_9NhRZTLzjZzwdsS2OPW4U2r31_1Uq-=poRDw@mail.gmail.com>
        <04832096-ED7F-4754-993D-F578D4A90843@jrtc27.com>
        <EEC90B2F-E972-475F-B058-918CDE401618@jrtc27.com>
        <20201101210102.GO534@brightrain.aerifal.cx>
        <29423184-A433-42D4-B635-CDEFE7271B40@jrtc27.com>
        <2AC632C0-EC00-4C4E-92DC-B7F238897C4C@jrtc27.com>
        <CALCETrWWcVhYoVuvovo558sXpA7X75jNpf8LA+w+k-dzyRiUcg@mail.gmail.com>
        <347eab9f-b64a-b124-ba7a-ee458e6407f3@gigawatt.nl>
Date:   Tue, 01 Aug 2023 09:15:06 +0200
In-Reply-To: <347eab9f-b64a-b124-ba7a-ee458e6407f3@gigawatt.nl> (Harald van
        Dijk's message of "Tue, 1 Aug 2023 01:43:40 +0100")
Message-ID: <87zg3b5j45.fsf@oldenburg.str.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

* Harald van Dijk:

> There is one complication that I think has not been mentioned yet:
> when _GNU_SOURCE is defined, glibc does provide a definition of struct
> msghdr in <sys/msg.h> with a field "__syscall_slong_t mtype;". This
> makes it slightly more likely that there is code out there in the wild
> that works fine with current kernels and would be broken by the
> fix. Given how rare x32 is, and how rare message queues are, this may
> still be acceptable, but I am mentioning it just in case this would
> cause a different approach to be preferred. And whatever is done, a
> fix should also be submitted to glibc.

What should glibc do here?  Just change the definition in the header to
long and ignore the breakage?

Thanks,
Florian