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;
Feedback-ID: i56a14606:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-334-g8c072af647-fm-20230330.001-g8c072af6
Mime-Version: 1.0
Message-Id: <3c2ba6f9-bea1-4510-8fbb-6521fab74a9d@app.fastmail.com>
In-Reply-To: <20230406124812.GA1589248@pevik>
References: <CA+G9fYtVXsKSbdxcTNiLc8oYRTBOZzWNQRF92daLE58NPbOkFg@mail.gmail.com>
 <96b67ae8-98dd-40fe-9dde-302e09d12551@app.fastmail.com>
 <20230406105646.GB1545779@pevik>
 <7234b8ab-db5c-4f4a-bb9e-ddef9f1a50d3@app.fastmail.com>
 <20230406124812.GA1589248@pevik>
Date:   Thu, 06 Apr 2023 14:53:13 +0200
From:   "Arnd Bergmann" <arnd@arndb.de>
To:     "Petr Vorel" <pvorel@suse.cz>
Cc:     "Naresh Kamboju" <naresh.kamboju@linaro.org>,
        "open list" <linux-kernel@vger.kernel.org>,
        "LTP List" <ltp@lists.linux.it>, llvm@lists.linux.dev,
        chrubis <chrubis@suse.cz>,
        "Nathan Chancellor" <nathan@kernel.org>,
        "Anders Roxell" <anders.roxell@linaro.org>,
        =?UTF-8?Q?Daniel_D=C3=ADaz?= <daniel.diaz@linaro.org>,
        "Benjamin Copeland" <ben.copeland@linaro.org>,
        "Tudor Cretu" <tudor.cretu@arm.com>
Subject: Re: LTP: list of failures on 32bit and compat mode
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Thu, Apr 6, 2023, at 14:48, Petr Vorel wrote:
>> On Thu, Apr 6, 2023, at 12:56, Petr Vorel wrote:

>> Ah, I see. This must be the padding code then, not the time64
>> conversion:
>
>> +int recvmmsg(int fd, struct mmsghdr *msgvec, unsigned int vlen, unsi=
gned int flags, struct timespec *timeout)
>> +{
>> +#if LONG_MAX > INT_MAX
>> +       struct mmsghdr *mh =3D msgvec;
>> +       unsigned int i;
>> +       for (i =3D vlen; i; i--, mh++)
>> +               mh->msg_hdr.__pad1 =3D mh->msg_hdr.__pad2 =3D 0;
>> +#endif
>
> I suppose this is a suggestion for fix in LTP. I'd expect is should go=
 into
> testcases/kernel/syscalls/sendmmsg/sendmmsg_var.h into static inline i=
nt
> sys_recvmmsg(...)
>
> But that at least on glibc 64bit compilation does not see __pad1 membe=
r:
>
> ../sendmmsg/sendmmsg_var.h: In function =E2=80=98sys_recvmmsg=E2=80=99:
> ../sendmmsg/sendmmsg_var.h:47:28: error: =E2=80=98struct msghdr=E2=80=99=
 has no member=20
> named =E2=80=98__pad1=E2=80=99
>    47 |                 mh->msg_hdr.__pad1 =3D mh->msg_hdr.__pad2 =3D =
0;
>       |                            ^

Sorry, I should have been clearer, the snippet I cited is
from the musl sources, and the __pad access is what causes the
segfault. The fix is to catch the fault on ltp, same as for the
time64 conversions.

      Arnd