linux-kernel - Re: LTP: list of failures on 32bit and compat mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEUSe7_JvM8SD15DVnXOsSyPhS+sF=9JEDzV+NW2XZ=MwVMBUw@mail.gmail.com>
Date:   Tue, 11 Apr 2023 23:22:07 -0600
From:   Daniel Díaz <daniel.diaz@...aro.org>
To:     Petr Vorel <pvorel@...e.cz>
Cc:     Naresh Kamboju <naresh.kamboju@...aro.org>,
        Arnd Bergmann <arnd@...db.de>,
        open list <linux-kernel@...r.kernel.org>,
        LTP List <ltp@...ts.linux.it>, llvm@...ts.linux.dev,
        chrubis <chrubis@...e.cz>, Nathan Chancellor <nathan@...nel.org>,
        Anders Roxell <anders.roxell@...aro.org>,
        Benjamin Copeland <ben.copeland@...aro.org>,
        Tudor Cretu <tudor.cretu@....com>
Subject: Re: LTP: list of failures on 32bit and compat mode

Hello!

On Tue, 11 Apr 2023 at 16:08, Petr Vorel <pvorel@...e.cz> wrote:
>
> > On Thu, 6 Apr 2023 at 16:26, Petr Vorel <pvorel@...e.cz> wrote:
>
> > > > On Thu, Apr 6, 2023, at 11:11, Naresh Kamboju wrote:
> > > > > Following LTP syscalls failed on the i386 and arm environments with
> > > > > Linux next / mainline kernels. The userspace is coming from Open
> > > > > Embedded kirkstone.
>
> > > > Thanks for the report and summary! I went through the list and found
> > > > 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 noticed
> > > > > on i386 only.
>
> > > > > This is not a new problem. We have been noticing these failures for 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@...make)
> > > > > (i686-linux-gnu-gcc (Debian 11.3.0-11) 11.3.0, GNU ld (GNU Binutils
> > > > > 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 = 9 : Bad file descriptor
> > > > > fstatfs02    2  TBROK  :  tst_sig.c:232: unexpected signal SIGSEGV(11)
> > > > > received (pid = 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 LTP 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íaz
daniel.diaz@...aro.org