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;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
Subject: Re: [PATCH v2] x86: Fix x32 System V message queue syscalls
From:   Jessica Clarke <jrtc27@jrtc27.com>
In-Reply-To: <347eab9f-b64a-b124-ba7a-ee458e6407f3@gigawatt.nl>
Date:   Tue, 1 Aug 2023 02:38:47 +0100
Cc:     Andy Lutomirski <luto@kernel.org>, Rich Felker <dalias@libc.org>,
        linux-x86_64@vger.kernel.org, Florian Weimer <fweimer@redhat.com>,
        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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5C330BFF-A81A-465D-BE7D-6DB6A7B263AF@jrtc27.com>
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>
To:     Harald van Dijk <harald@gigawatt.nl>
Precedence: bulk

On 1 Aug 2023, at 01:43, Harald van Dijk <harald@gigawatt.nl> wrote:
>=20
> On 06/12/2020 22:55, Andy Lutomirski wrote:
>> On Sat, Dec 5, 2020 at 4:01 PM Jessica Clarke <jrtc27@jrtc27.com> =
wrote:
>>>=20
>>> Ping?
>> Can you submit patches implementing my proposal?  One is your =
existing
>> patch plus fixing struct msghdr, with Cc: stable@vger.kernel.org at
>> the bottom.  The second is a removal of struct msghdr from uapi,
>> moving it into include/inux (no uapi) if needed.  The second should
>> not cc stable.
>=20
> Hi,
>=20
> This looks like it was forgotten, but it is still needed. Jessica, are =
you interested in submitting the requested change? If not, would it be =
okay if I do so? I have been running this locally for a long time now.

Hi,
Please feel free to; sorry that it dropped off my radar. Part of the
issue is my laptop no longer being x86, making it more annoying to test.

> 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.

Given POSIX is very clear on how msghdr works I think we have to break
whatever oddball code out there might be using this. The alternative is
violating POSIX in a way that makes correct code compile fine but fail
at run time on x32, which is a terrible place to be, especially when
the =E2=80=9Cfix=E2=80=9D is to special-case x32 to go against what =
POSIX says. I just
can=E2=80=99t see how that=E2=80=99s a good place to stay in, even if =
something might
break when we fix this bug.

Thanks,
Jess

> (musl define struct msghdr as well, but defines mtype unconditionally =
as having type long, so if this approach is still preferred, needs no =
changes.)
>=20
> Cheers,
> Harald van Dijk