All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: "Daniel Díaz" <daniel.diaz@linaro.org>
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>
Subject: Re: LTP: list of failures on 32bit and compat mode
Date: Wed, 12 Apr 2023 09:14:52 +0200	[thread overview]
Message-ID: <20230412071452.GD1949572@pevik> (raw)
In-Reply-To: <CAEUSe7_JvM8SD15DVnXOsSyPhS+sF=9JEDzV+NW2XZ=MwVMBUw@mail.gmail.com>

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

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

Great, thank you! Using the latest release (or git master) really saves of all
of us.

Kind regards,
Petr

> Thanks for looking into this! Greetings!

> Daniel Díaz
> daniel.diaz@linaro.org

WARNING: multiple messages have this Message-ID (diff)
From: Petr Vorel <pvorel@suse.cz>
To: "Daniel Díaz" <daniel.diaz@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 09:14:52 +0200	[thread overview]
Message-ID: <20230412071452.GD1949572@pevik> (raw)
In-Reply-To: <CAEUSe7_JvM8SD15DVnXOsSyPhS+sF=9JEDzV+NW2XZ=MwVMBUw@mail.gmail.com>

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

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

Great, thank you! Using the latest release (or git master) really saves of all
of us.

Kind regards,
Petr

> Thanks for looking into this! Greetings!

> Daniel Díaz
> daniel.diaz@linaro.org

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2023-04-12  7:14 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
2023-04-11 22:08         ` [LTP] " 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 [this message]
2023-04-12  7:14             ` 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=20230412071452.GD1949572@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.