All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Arnd Bergmann <arnd@arndb.de>
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>,
	"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: Thu, 6 Apr 2023 14:48:12 +0200	[thread overview]
Message-ID: <20230406124812.GA1589248@pevik> (raw)
In-Reply-To: <7234b8ab-db5c-4f4a-bb9e-ddef9f1a50d3@app.fastmail.com>

Hi all,

> On Thu, Apr 6, 2023, at 12:56, Petr Vorel wrote:
> >> On Thu, Apr 6, 2023, at 11:11, Naresh Kamboju wrote:

> >> > mq_timedreceive01
> >> > mq_timedreceive01.c:197: TPASS: mq_timedreceive() failed expectedly: EINTR (4)
> >> > tst_test.c:1581: TBROK: Test killed by SIGSEGV!

> >> I think this is the same problem as fstatfs02, where ltp passes
> >> an invalid pointer and expects EFAULT, but musl touches the data
> >> first in order to do the time64 conversion. Needs the same fix.

> > FYI mq_timedreceive01 is broken on 32bit systems with glibc
> > (in current LTP master):


> > EINTR (4)
> > tst_test.c:1618: TBROK: Test killed by SIGSEGV!

> Right, I see this has the same time64 logic as musl now.

> >> > recvmmsg01.c:92: TPASS: recvmmsg() overflow in nanoseconds in timeout
> >> > : EINVAL (22)
> >> > tst_test.c:1581: TBROK: Test killed by SIGSEGV!

> >> Same time64 conversion issue as above.

> > Besides the same problem with shm permissions on musl I see SIGSEGV also on
> > 64bit musl on current LTP master.

> Ah, I see. This must be the padding code then, not the time64
> conversion:

> +int recvmmsg(int fd, struct mmsghdr *msgvec, unsigned int vlen, unsigned int flags, struct timespec *timeout)
> +{
> +#if LONG_MAX > INT_MAX
> +       struct mmsghdr *mh = msgvec;
> +       unsigned int i;
> +       for (i = vlen; i; i--, mh++)
> +               mh->msg_hdr.__pad1 = mh->msg_hdr.__pad2 = 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 int
sys_recvmmsg(...)

But that at least on glibc 64bit compilation does not see __pad1 member:

../sendmmsg/sendmmsg_var.h: In function ‘sys_recvmmsg’:
../sendmmsg/sendmmsg_var.h:47:28: error: ‘struct msghdr’ has no member named ‘__pad1’
   47 |                 mh->msg_hdr.__pad1 = mh->msg_hdr.__pad2 = 0;
      |                            ^

Kind regards,
Petr

>        Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Petr Vorel <pvorel@suse.cz>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Benjamin Copeland <ben.copeland@linaro.org>,
	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: Thu, 6 Apr 2023 14:48:12 +0200	[thread overview]
Message-ID: <20230406124812.GA1589248@pevik> (raw)
In-Reply-To: <7234b8ab-db5c-4f4a-bb9e-ddef9f1a50d3@app.fastmail.com>

Hi all,

> On Thu, Apr 6, 2023, at 12:56, Petr Vorel wrote:
> >> On Thu, Apr 6, 2023, at 11:11, Naresh Kamboju wrote:

> >> > mq_timedreceive01
> >> > mq_timedreceive01.c:197: TPASS: mq_timedreceive() failed expectedly: EINTR (4)
> >> > tst_test.c:1581: TBROK: Test killed by SIGSEGV!

> >> I think this is the same problem as fstatfs02, where ltp passes
> >> an invalid pointer and expects EFAULT, but musl touches the data
> >> first in order to do the time64 conversion. Needs the same fix.

> > FYI mq_timedreceive01 is broken on 32bit systems with glibc
> > (in current LTP master):


> > EINTR (4)
> > tst_test.c:1618: TBROK: Test killed by SIGSEGV!

> Right, I see this has the same time64 logic as musl now.

> >> > recvmmsg01.c:92: TPASS: recvmmsg() overflow in nanoseconds in timeout
> >> > : EINVAL (22)
> >> > tst_test.c:1581: TBROK: Test killed by SIGSEGV!

> >> Same time64 conversion issue as above.

> > Besides the same problem with shm permissions on musl I see SIGSEGV also on
> > 64bit musl on current LTP master.

> Ah, I see. This must be the padding code then, not the time64
> conversion:

> +int recvmmsg(int fd, struct mmsghdr *msgvec, unsigned int vlen, unsigned int flags, struct timespec *timeout)
> +{
> +#if LONG_MAX > INT_MAX
> +       struct mmsghdr *mh = msgvec;
> +       unsigned int i;
> +       for (i = vlen; i; i--, mh++)
> +               mh->msg_hdr.__pad1 = mh->msg_hdr.__pad2 = 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 int
sys_recvmmsg(...)

But that at least on glibc 64bit compilation does not see __pad1 member:

../sendmmsg/sendmmsg_var.h: In function ‘sys_recvmmsg’:
../sendmmsg/sendmmsg_var.h:47:28: error: ‘struct msghdr’ has no member named ‘__pad1’
   47 |                 mh->msg_hdr.__pad1 = mh->msg_hdr.__pad2 = 0;
      |                            ^

Kind regards,
Petr

>        Arnd

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

  reply	other threads:[~2023-04-06 12:48 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 [this message]
2023-04-06 12:48         ` 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
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=20230406124812.GA1589248@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.