From: Petr Vorel <pvorel@suse.cz>
To: Naresh Kamboju <naresh.kamboju@linaro.org>
Cc: "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>,
"Daniel Díaz" <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
Date: Wed, 12 Apr 2023 00:08:11 +0200 [thread overview]
Message-ID: <20230411220811.GA1798729@pevik> (raw)
In-Reply-To: <CA+G9fYs461=iJqZqKe8_iRkfsMemSSA+ByOPRc9k-kBf4Hp8og@mail.gmail.com>
> 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 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@tuxmake)
> > > > (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.
> I will keep you posted with the latest findings.
Thanks!
Kind regards,
Petr
> - Naresh
WARNING: multiple messages have this Message-ID (diff)
From: Petr Vorel <pvorel@suse.cz>
To: Naresh Kamboju <naresh.kamboju@linaro.org>
Cc: Benjamin Copeland <ben.copeland@linaro.org>,
Arnd Bergmann <arnd@arndb.de>,
llvm@lists.linux.dev, open list <linux-kernel@vger.kernel.org>,
Nathan Chancellor <nathan@kernel.org>,
LTP List <ltp@lists.linux.it>
Subject: Re: [LTP] LTP: list of failures on 32bit and compat mode
Date: Wed, 12 Apr 2023 00:08:11 +0200 [thread overview]
Message-ID: <20230411220811.GA1798729@pevik> (raw)
In-Reply-To: <CA+G9fYs461=iJqZqKe8_iRkfsMemSSA+ByOPRc9k-kBf4Hp8og@mail.gmail.com>
> 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 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@tuxmake)
> > > > (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.
> I will keep you posted with the latest findings.
Thanks!
Kind regards,
Petr
> - Naresh
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2023-04-11 22:08 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-06 9:11 LTP: list of failures on 32bit and compat mode Naresh Kamboju
2023-04-06 9:11 ` [LTP] " Naresh Kamboju
2023-04-06 9:54 ` Arnd Bergmann
2023-04-06 9:54 ` [LTP] " Arnd Bergmann
2023-04-06 10:56 ` Petr Vorel
2023-04-06 10:56 ` [LTP] " Petr Vorel
2023-04-06 11:23 ` Arnd Bergmann
2023-04-06 11:23 ` [LTP] " Arnd Bergmann
2023-04-06 12:48 ` Petr Vorel
2023-04-06 12:48 ` [LTP] " Petr Vorel
2023-04-06 12:53 ` Arnd Bergmann
2023-04-06 12:53 ` [LTP] " Arnd Bergmann
2023-04-06 13:17 ` Petr Vorel
2023-04-06 13:17 ` [LTP] " Petr Vorel
2023-04-06 13:21 ` Arnd Bergmann
2023-04-06 13:21 ` [LTP] " Arnd Bergmann
2023-04-06 13:58 ` Cyril Hrubis
2023-04-06 13:58 ` [LTP] " Cyril Hrubis
2023-04-11 16:45 ` Naresh Kamboju
2023-04-11 16:45 ` [LTP] " Naresh Kamboju
2023-04-11 17:37 ` Naresh Kamboju
2023-04-11 17:37 ` [LTP] " Naresh Kamboju
2023-04-11 22:08 ` Petr Vorel [this message]
2023-04-11 22:08 ` Petr Vorel
2023-04-12 5:22 ` Daniel Díaz
2023-04-12 5:22 ` [LTP] " Daniel Díaz
2023-04-12 7:14 ` Petr Vorel
2023-04-12 7:14 ` [LTP] " Petr Vorel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230411220811.GA1798729@pevik \
--to=pvorel@suse.cz \
--cc=anders.roxell@linaro.org \
--cc=arnd@arndb.de \
--cc=ben.copeland@linaro.org \
--cc=chrubis@suse.cz \
--cc=daniel.diaz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=ltp@lists.linux.it \
--cc=naresh.kamboju@linaro.org \
--cc=nathan@kernel.org \
--cc=tudor.cretu@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.