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;
MIME-Version: 1.0
References: <CA+G9fYtVXsKSbdxcTNiLc8oYRTBOZzWNQRF92daLE58NPbOkFg@mail.gmail.com>
 <96b67ae8-98dd-40fe-9dde-302e09d12551@app.fastmail.com> <20230406105646.GB1545779@pevik>
 <CA+G9fYs461=iJqZqKe8_iRkfsMemSSA+ByOPRc9k-kBf4Hp8og@mail.gmail.com> <20230411220811.GA1798729@pevik>
In-Reply-To: <20230411220811.GA1798729@pevik>
From:   =?UTF-8?B?RGFuaWVsIETDrWF6?= <daniel.diaz@linaro.org>
Date:   Tue, 11 Apr 2023 23:22:07 -0600
Message-ID: <CAEUSe7_JvM8SD15DVnXOsSyPhS+sF=9JEDzV+NW2XZ=MwVMBUw@mail.gmail.com>
Subject: Re: LTP: list of failures on 32bit and compat mode
To:     Petr Vorel <pvorel@suse.cz>
Cc:     Naresh Kamboju <naresh.kamboju@linaro.org>,
        Arnd Bergmann <arnd@arndb.de>,
        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>,
        Benjamin Copeland <ben.copeland@linaro.org>,
        Tudor Cretu <tudor.cretu@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hello!

On Tue, 11 Apr 2023 at 16:08, Petr Vorel <pvorel@suse.cz> wrote:
>
> > On Thu, 6 Apr 2023 at 16:26, Petr Vorel <pvorel@suse.cz> wrote:
>
> > > > On Thu, Apr 6, 2023, at 11:11, Naresh Kamboju wrote:
> > > > > Following LTP syscalls failed on the i386 and arm environments wi=
th
> > > > > Linux next / mainline kernels. The userspace is coming from Open
> > > > > Embedded kirkstone.
>
> > > > Thanks for the report and summary! I went through the list and foun=
d
> > > > that most if not all of the bugs looks like incompatibilities
> > > > with musl, not with 32-bit. It's probably not well tested with
> > > > musl.
>
> > > > Can you try again with glibc and see if there are any remaining
> > > > issues then? LTP should probably be fixed to work with both, but
> > > > if nobody has done that so far, it's likely that this has come
> > > > up in the past but ran into problems upstreaming the fixes.
>
> > > > > Anyone seeing this problem on 32-bit i386 or arm ?
> > > > > You get to see "segfault" in the following logs that have been no=
ticed
> > > > > on i386 only.
>
> > > > > This is not a new problem. We have been noticing these failures f=
or a
> > > > > really long time.
> > > > > Would it be worth investigating the reason for failures on 32bit =
architectures ?
>
> > > > > Test logs,
> > > > > -----
> > > > > [    0.000000] Linux version 6.3.0-rc5-next-20230406 (tuxmake@tux=
make)
> > > > > (i686-linux-gnu-gcc (Debian 11.3.0-11) 11.3.0, GNU ld (GNU Binuti=
ls
> > > > > for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC @1680759389
>
>
> > > > > Test environment: i386
> > > > > Suite: ltp-syscalls
> > > > > Toolchain: gcc-11
>
>
> > > > > fstatfs02
> > > > > fstatfs02    1  TPASS  :  expected failure - errno =3D 9 : Bad fi=
le descriptor
> > > > > fstatfs02    2  TBROK  :  tst_sig.c:232: unexpected signal SIGSEG=
V(11)
> > > > > received (pid =3D 17841).
> > > > > fstatfs02    3  TBROK  :  tst_sig.c:232: Remaining cases broken
> > > This is IMHO using the old LTP API.
> > > testcases/kernel/syscalls/fstatfs/fstatfs02.c was converted to new LT=
P API in
> > > 5a8f89d35 ("syscalls/statfs02, fstatfs02: Convert to new API"), which=
 was
> > > released in 20220930. There is already newer release 20230127.
> > > Generally it's safer to test mainline kernel with LTP master,
> > > but this fix has already been in the latest LTP release 20230127.
> > > And this error has been later fixed with
> > > 492542072 ("syscalls/statfs02, fstatfs02: Accept segfault instead of =
EFAULT")
> I'm sorry, I was wrong stating that unexpected signal SIGSEGV(11)
> error was fixed by 492542072.
>
> > Thanks for insite about the failed test investigations.
>
>
> > > @Naresh which LTP do you use for testing? It must be some older LTP :=
(.
>
> > Our build system started running LTP version 20230127.
> I'm sorry, I obviously misinterpreted the test output as old LTP code.

No, you were right! We were running an older version and because of
this discussion we have now updated to 20230127 in Kirkstone. This
update from Naresh and these findings are with 20230127.

Thanks for looking into this! Greetings!

Daniel D=C3=ADaz
daniel.diaz@linaro.org