Following LTP syscalls failed on the i386 and arm environments with
Linux next / mainline kernels. The userspace is coming from Open
Embedded kirkstone.
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
---
ioctl03
ioctl03.c:85: TFAIL: (UNKNOWN 0x40)
----
mq_timedreceive01
[ 283.875014] mq_timedreceive[2354]: segfault at b7f5a004 ip b7dc1b0f
sp bfc4dde0 error 4 in libc.so.6[b7d52000+175000] likely on CPU 2
(core 2, socket 0)
[ 283.894804] Code: 65 c7 07 4b 00 00 00 b8 ff ff ff ff e9 7b fe ff
ff 8d b4 26 00 00 00 00 8d 76 00 f3 0f 1e fb 83 ec 1c 8b 44 24 30 85
c0 74 1d <8b> 50 04 c7 44 24 0c 00 00 00 00 8b 00 89 54 24 08 89 04 24
c1 f8
[ 283.913703] audit: type=1701 audit(1680761716.789:31):
auid=4294967295 uid=0 gid=0 ses=4294967295 subj=kernel pid=2354
comm=\"mq_timedreceive\"
exe=\"/opt/ltp/testcases/bin/mq_timedreceive01\" sig=11 res=1
0
mq_timedreceive01
mq_timedreceive01.c:197: TPASS: mq_timedreceive() failed expectedly: EINTR (4)
tst_test.c:1581: TBROK: Test killed by SIGSEGV!
----
mq_timedsend01
[ 283.982220] mq_timedsend01[2357]: segfault at b7f06004 ip b7d6dd6f
sp bfb58fe0 error 4 in libc.so.6[b7cfe000+175000] likely on CPU 0
(core 0, socket 0)
[ 283.996745] Code: 65 c7 07 4b 00 00 00 b8 ff ff ff ff e9 7b fe ff
ff 8d b4 26 00 00 00 00 8d 76 00 f3 0f 1e fb 83 ec 1c 8b 44 24 30 85
c0 74 1d <8b> 50 04 c7 44 24 0c 00 00 00 00 8b 00 89 54 24 08 89 04 24
c1 f8
lls/mq_notify/..[ 284.015564] audit: type=1701
audit(1680761716.891:32): auid=4294967295 uid=0 gid=0 ses=4294967295
subj=kernel pid=2357 comm=\"mq_timedsend01\"
exe=\"/opt/ltp/testcases/bin/mq_timedsend01\" sig=11 res=1
/utils/mq.h:70: TINFO: receive 1/1 message
mq_timedsend01.c:210: TPASS: mq_timedsend() failed expectedly: EFAULT (14)
tst_test.c:1581: TBROK: Test killed by SIGSEGV!
---
pread02_64
tst_test.c:1524: TINFO: Timeout per run is 0h 05m 00s
pread02.[ 319.705083] /dev/zero: Can't open blockdev
c:44: TPASS: pread(3, 1024, 0) (null) : ESPIPE (29)
tst_test.c:1581: TBROK: Test killed by SIGSEGV!
---
recvmmsg01
[ 369.451748] recvmmsg01[3821]: segfault at b7cb1004 ip b7dd7413 sp
bf992430 error 4 in libc.so.6[b7cda000+175000] likely on CPU 3 (core
3, socket 0)
[ 369.466232] Code: 26 00 00 00 00 66 90 f3 0f 1e fb 55 57 56 53 83
ec 2c 8b 5c 24 50 8b 44 24 40 8b 54 24 44 8b 4c 24 48 8b 74 24 4c 85
db 74 55 <8b> 7b 04 c7 44 24 1c 00 00 00 00 83 ec 08 8b 2b 89 7c 24 14
8b 7c
[ 369.485043] audit: type=1701 audit(1680761802.360:44):
auid=4294967295 uid=0 gid=0 ses=4294967295 subj=kernel pid=3821
comm=\"recvmmsg01\" exe=\"/opt/ltp/testcases/bin/recvmmsg01\" sig=11
res=1
[ 369.496491] mmap: remap_file_page (3822) uses deprecated
remap_file_pages() syscall. See Documentation/mm/remap_file_pages.rst.
recvmmsg01.c:92: TPASS: recvmmsg() overflow in nanoseconds in timeout
: EINVAL (22)
tst_test.c:1581: TBROK: Test killed by SIGSEGV!
---
semctl03
[ 441.271399] semctl03[6093]: segfault at 0 ip b7e53fc0 sp bf93c0a0
error 4 in libc.so.6[b7d56000+175000] likely on CPU 1 (core 1, socket
0)
[ 441.284432] Code: 24 5c ff 74 24 5c e8 cf fd ff ff 83 c4 10 85 c0
78 0e ba 04 00 14 00 0f a3 fa 0f 82 ba 00 00 00 83 c4 40 5b 5e 5f c3
8d 76 00 <8b> 03 31 d2 89 e6 66 0f 6e ca 89 04 24 8b 43 04 89 44 24 04
8b 43
[ 441.303267] audit: type=1701 audit(1680761874.178:46):
auid=4294967295 uid=0 gid=0 ses=4294967295 subj=kernel pid=6093
comm=\"semctl03\" exe=\"/opt/ltp/testcases/bin/semctl03\" sig=11 res=1
semctl03.c:73: TPASS: semctl() with invalid IPC command : EINVAL (22)
tst_test.c:1581: TBROK: Test killed by SIGSEGV!
semctl04
semctl04.c:69: TBROK: semget(1628514830, 10, 600) failed: EEXIST (17)
semctl05
semctl05.c:54: TBROK: semget(1628514830, 10, 780) failed: EEXIST (17)
semctl07
semctl07.c:41: TFAIL: sem_nsems = 10, expected 1
----
sigtimedwait01
[ 486.624973] sigtimedwait01[6644]: segfault at 5 ip b7d9758f sp
bfda7290 error 4 in libc.so.6[b7d80000+175000] likely on CPU 1 (core
1, socket 0)
[ 486.639052] Code: c7 03 4b 00 00 00 b8 ff ff ff ff e9 3b fe ff ff
8d b4 26 00 00 00 00 8d 74 26 00 f3 0f 1e fb 83 ec 1c 8b 44 24 28 85
c0 74 1d <8b> 50 04 c7 44 24 0c 00 00 00 00 8b 00 89 54 24 08 89 04 24
c1 f8
[ 486.659213] audit: type=1701 audit(1680761919.535:49):
auid=4294967295 uid=0 gid=0 ses=4294967295 subj=kernel pid=6644
comm=\"sigtimedwait01\" exe=\"/opt/ltp/testcases/bin/sigtimedwait01\"
sig=11 res=1
sigwait.c:344: TPASS: Child exited with expected code
tst_test.c:1581: TBROK: Test killed by SIGSEGV!
---
statfs02
statfs02 4 TPASS : expected failure: TEST_ERRNO=EFAULT(14): Bad address
statfs02 5 TBROK : tst_sig.c:232: unexpected signal SIGSEGV(11)
received (pid = 6728).
statfs02 6 TBROK : tst_sig.c:232: Remaining cases broken
---
statx01
statx01.c:138: TPASS: stx_nlink(1) is c[ 833.666410] /dev/zero: Can't
open blockdev
orrect
statx01.c:82: TFAIL: statx.stx_mnt_id(421) is different from
mount_id(34280324422697381)[ 833.678950] /dev/zero: Can't open
blockdev
in /proc/self/mountinfo
statx01.c:88: TPASS: /proc/12304/fdinfo/3 mnt_id: = 421
---
ustat01
tst_test.c:1524: TINFO: Timeout per run is 0h 05m 00s
ustat01.c:39: TBROK: stat(/,0xbfb96278) failed: EOVERFLOW (75)
tst_test.c:1524: TINFO: Timeout per run is 0h 05m 00s
ustat02.c:57: TBROK: stat(/,0xbfa11098) failed: EOVERFLOW (75)
Details log:
https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230406/testrun/16119999/suite/ltp-syscalls/test/fstatfs02/log
List of test cases failed:
i386:
https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230406/testrun/16119999/suite/ltp-syscalls/tests/
arm - x15 device logs:
https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230406/testrun/16120012/suite/ltp-syscalls/tests/
https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230406/testrun/16120012/suite/ltp-syscalls/test/fstatfs02/log
Test environment: qemu_x86_64-compat
https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230406/testrun/16119789/suite/ltp-syscalls/tests/
Test environment: juno-r2-compat
https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230406/testrun/16120000/suite/ltp-syscalls/tests/
- Naresh
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
I think this is the same thing that Tudor reported last year,
looks like valid behavior of the libc implementation that should
be handled by ltp:
https://lore.kernel.org/all/[email protected]/
Are you building the 32-bit x86 userspace with musl or glibc?
> ---
> ioctl03
> ioctl03.c:85: TFAIL: (UNKNOWN 0x40)
0x40 was added by kernel commit 195624d9c26b ("tun: support not
enabling carrier in TUNSETIFF"), this needs to be fixed in ltp
as well. Should not be specific to 32-bit though.
> ----
> mq_timedreceive01
>
> [ 283.875014] mq_timedreceive[2354]: segfault at b7f5a004 ip b7dc1b0f
> sp bfc4dde0 error 4 in libc.so.6[b7d52000+175000] likely on CPU 2
> (core 2, socket 0)
> [ 283.894804] Code: 65 c7 07 4b 00 00 00 b8 ff ff ff ff e9 7b fe ff
> ff 8d b4 26 00 00 00 00 8d 76 00 f3 0f 1e fb 83 ec 1c 8b 44 24 30 85
> c0 74 1d <8b> 50 04 c7 44 24 0c 00 00 00 00 8b 00 89 54 24 08 89 04 24
> c1 f8
> [ 283.913703] audit: type=1701 audit(1680761716.789:31):
> auid=4294967295 uid=0 gid=0 ses=4294967295 subj=kernel pid=2354
> comm=\"mq_timedreceive\"
> exe=\"/opt/ltp/testcases/bin/mq_timedreceive01\" sig=11 res=1
> 0
>
> 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.
> ----
> mq_timedsend01
>
> [ 283.982220] mq_timedsend01[2357]: segfault at b7f06004 ip b7d6dd6f
> sp bfb58fe0 error 4 in libc.so.6[b7cfe000+175000] likely on CPU 0
> (core 0, socket 0)
> [ 283.996745] Code: 65 c7 07 4b 00 00 00 b8 ff ff ff ff e9 7b fe ff
> ff 8d b4 26 00 00 00 00 8d 76 00 f3 0f 1e fb 83 ec 1c 8b 44 24 30 85
> c0 74 1d <8b> 50 04 c7 44 24 0c 00 00 00 00 8b 00 89 54 24 08 89 04 24
> c1 f8
> lls/mq_notify/..[ 284.015564] audit: type=1701
> audit(1680761716.891:32): auid=4294967295 uid=0 gid=0 ses=4294967295
> subj=kernel pid=2357 comm=\"mq_timedsend01\"
> exe=\"/opt/ltp/testcases/bin/mq_timedsend01\" sig=11 res=1
> /utils/mq.h:70: TINFO: receive 1/1 message
>
> mq_timedsend01.c:210: TPASS: mq_timedsend() failed expectedly: EFAULT (14)
> tst_test.c:1581: TBROK: Test killed by SIGSEGV!
same here
> ---
>
> pread02_64
>
> tst_test.c:1524: TINFO: Timeout per run is 0h 05m 00s
> pread02.[ 319.705083] /dev/zero: Can't open blockdev
> c:44: TPASS: pread(3, 1024, 0) (null) : ESPIPE (29)
> tst_test.c:1581: TBROK: Test killed by SIGSEGV!
This looks like LTP is calling the wrong function here
for musl: it passes D_FILE_OFFSET_BITS=64 for some tests
but not others, but on musl you always get the 64-bit
behavior.
> ---
> recvmmsg01
>
> [ 369.451748] recvmmsg01[3821]: segfault at b7cb1004 ip b7dd7413 sp
> bf992430 error 4 in libc.so.6[b7cda000+175000] likely on CPU 3 (core
> 3, socket 0)
> [ 369.466232] Code: 26 00 00 00 00 66 90 f3 0f 1e fb 55 57 56 53 83
> ec 2c 8b 5c 24 50 8b 44 24 40 8b 54 24 44 8b 4c 24 48 8b 74 24 4c 85
> db 74 55 <8b> 7b 04 c7 44 24 1c 00 00 00 00 83 ec 08 8b 2b 89 7c 24 14
> 8b 7c
> [ 369.485043] audit: type=1701 audit(1680761802.360:44):
> auid=4294967295 uid=0 gid=0 ses=4294967295 subj=kernel pid=3821
> comm=\"recvmmsg01\" exe=\"/opt/ltp/testcases/bin/recvmmsg01\" sig=11
> res=1
> [ 369.496491] mmap: remap_file_page (3822) uses deprecated
> remap_file_pages() syscall. See Documentation/mm/remap_file_pages.rst.
>
>
> 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.
> ---
> semctl03
>
> [ 441.271399] semctl03[6093]: segfault at 0 ip b7e53fc0 sp bf93c0a0
> error 4 in libc.so.6[b7d56000+175000] likely on CPU 1 (core 1, socket
> 0)
> [ 441.284432] Code: 24 5c ff 74 24 5c e8 cf fd ff ff 83 c4 10 85 c0
> 78 0e ba 04 00 14 00 0f a3 fa 0f 82 ba 00 00 00 83 c4 40 5b 5e 5f c3
> 8d 76 00 <8b> 03 31 d2 89 e6 66 0f 6e ca 89 04 24 8b 43 04 89 44 24 04
> 8b 43
> [ 441.303267] audit: type=1701 audit(1680761874.178:46):
> auid=4294967295 uid=0 gid=0 ses=4294967295 subj=kernel pid=6093
> comm=\"semctl03\" exe=\"/opt/ltp/testcases/bin/semctl03\" sig=11 res=1
>
> semctl03.c:73: TPASS: semctl() with invalid IPC command : EINVAL (22)
> tst_test.c:1581: TBROK: Test killed by SIGSEGV!
time64 again
> semctl04
> semctl04.c:69: TBROK: semget(1628514830, 10, 600) failed: EEXIST (17)
>
> semctl05
> semctl05.c:54: TBROK: semget(1628514830, 10, 780) failed: EEXIST (17)
These are probably broken by semctl03 having failed first, and
they should be fine if you clear out the semaphore first, or
skip the semctl03 test.
> ----
> sigtimedwait01
>
>
> [ 486.624973] sigtimedwait01[6644]: segfault at 5 ip b7d9758f sp
> bfda7290 error 4 in libc.so.6[b7d80000+175000] likely on CPU 1 (core
> 1, socket 0)
> [ 486.639052] Code: c7 03 4b 00 00 00 b8 ff ff ff ff e9 3b fe ff ff
> 8d b4 26 00 00 00 00 8d 74 26 00 f3 0f 1e fb 83 ec 1c 8b 44 24 28 85
> c0 74 1d <8b> 50 04 c7 44 24 0c 00 00 00 00 8b 00 89 54 24 08 89 04 24
> c1 f8
> [ 486.659213] audit: type=1701 audit(1680761919.535:49):
> auid=4294967295 uid=0 gid=0 ses=4294967295 subj=kernel pid=6644
> comm=\"sigtimedwait01\" exe=\"/opt/ltp/testcases/bin/sigtimedwait01\"
> sig=11 res=1
>
>
> sigwait.c:344: TPASS: Child exited with expected code
> tst_test.c:1581: TBROK: Test killed by SIGSEGV!
sigwait calls sigtimedwait and copies the signal number into
the provided pointer, so apparently a similar problem. I couldn't
find the testcase in the ltp sources, only see a sigwait01.c
not sigwait.c, but that doesn't trigger the bug.
> ---
>
>
> statfs02
>
> statfs02 4 TPASS : expected failure: TEST_ERRNO=EFAULT(14): Bad address
> statfs02 5 TBROK : tst_sig.c:232: unexpected signal SIGSEGV(11)
> received (pid = 6728).
> statfs02 6 TBROK : tst_sig.c:232: Remaining cases broken
I don't know why musl copes statfs, but this is yet another instance.
Not time64
>
> statx01
>
> statx01.c:138: TPASS: stx_nlink(1) is c[ 833.666410] /dev/zero: Can't
> open blockdev
> orrect
> statx01.c:82: TFAIL: statx.stx_mnt_id(421) is different from
> mount_id(34280324422697381)[ 833.678950] /dev/zero: Can't open
> blockdev
> in /proc/self/mountinfo
> statx01.c:88: TPASS: /proc/12304/fdinfo/3 mnt_id: = 421
No idea, possibly some type mismatch between definitions in musl
and ltp.
> ---
> ustat01
>
> tst_test.c:1524: TINFO: Timeout per run is 0h 05m 00s
> ustat01.c:39: TBROK: stat(/,0xbfb96278) failed: EOVERFLOW (75)
>
> tst_test.c:1524: TINFO: Timeout per run is 0h 05m 00s
> ustat02.c:57: TBROK: stat(/,0xbfa11098) failed: EOVERFLOW (75)
I think the definition of 'struct ustat' in ltp/include/lapi/ustat.h
is wrong and does not match the kernel. This uses a libc-provided
'ino_t', which is probably different from what the kernel expects
here.
Arnd
> 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")
@Naresh which LTP do you use for testing? It must be some older LTP :(.
> I think this is the same thing that Tudor reported last year,
> looks like valid behavior of the libc implementation that should
> be handled by ltp:
> https://lore.kernel.org/all/[email protected]/
> Are you building the 32-bit x86 userspace with musl or glibc?
> > ---
> > ioctl03
> > ioctl03.c:85: TFAIL: (UNKNOWN 0x40)
> 0x40 was added by kernel commit 195624d9c26b ("tun: support not
> enabling carrier in TUNSETIFF"), this needs to be fixed in ltp
> as well. Should not be specific to 32-bit though.
Again, this error has been fixed in LTP master in
538a44741 ("syscalls/ioctl03: add IFF_NO_CARRIER flag")
> > ----
> > mq_timedreceive01
> > [ 283.875014] mq_timedreceive[2354]: segfault at b7f5a004 ip b7dc1b0f
> > sp bfc4dde0 error 4 in libc.so.6[b7d52000+175000] likely on CPU 2
> > (core 2, socket 0)
> > [ 283.894804] Code: 65 c7 07 4b 00 00 00 b8 ff ff ff ff e9 7b fe ff
> > ff 8d b4 26 00 00 00 00 8d 76 00 f3 0f 1e fb 83 ec 1c 8b 44 24 30 85
> > c0 74 1d <8b> 50 04 c7 44 24 0c 00 00 00 00 8b 00 89 54 24 08 89 04 24
> > c1 f8
> > [ 283.913703] audit: type=1701 audit(1680761716.789:31):
> > auid=4294967295 uid=0 gid=0 ses=4294967295 subj=kernel pid=2354
> > comm=\"mq_timedreceive\"
> > exe=\"/opt/ltp/testcases/bin/mq_timedreceive01\" sig=11 res=1
> > 0
I suppose none of the issues can be related to audit log.
> > 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):
tst_test.c:1558: TINFO: Timeout per run is 0h 00m 30s
mq_timedreceive01.c:140: TINFO: Testing variant: vDSO or syscall with libc spec
mq_timedreceive01.c:223: TPASS: mq_timedreceive() returned 0, priority 0, length: 8192
mq_timedreceive01.c:223: TPASS: mq_timedreceive() returned 1, priority 0, length: 8192
mq_timedreceive01.c:223: TPASS: mq_timedreceive() returned 8192, priority 0, length: 8192
mq_timedreceive01.c:223: TPASS: mq_timedreceive() returned 1, priority 32767, length: 8192
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedreceive/../utils/mq.h:70: TINFO: receive 1/1 message
mq_timedreceive01.c:197: TPASS: mq_timedreceive() failed expectedly: EMSGSIZE (90)
mq_timedreceive01.c:197: TPASS: mq_timedreceive() failed expectedly: EBADF (9)
mq_timedreceive01.c:197: TPASS: mq_timedreceive() failed expectedly: EBADF (9)
mq_timedreceive01.c:197: TPASS: mq_timedreceive() failed expectedly: EBADF (9)
mq_timedreceive01.c:197: TPASS: mq_timedreceive() failed expectedly: EAGAIN/EWOULDBLOCK (11)
mq_timedreceive01.c:197: TPASS: mq_timedreceive() failed expectedly: EINVAL (22)
mq_timedreceive01.c:197: TPASS: mq_timedreceive() failed expectedly: EINVAL (22)
mq_timedreceive01.c:197: TPASS: mq_timedreceive() failed expectedly: EINVAL (22)
mq_timedreceive01.c:197: TPASS: mq_timedreceive() failed expectedly: ETIMEDOUT (110)
mq_timedreceive01.c:197: TPASS: mq_timedreceive() failed expectedly: EINTR (4)
tst_test.c:1618: TBROK: Test killed by SIGSEGV!
> > ----
> > mq_timedsend01
> > [ 283.982220] mq_timedsend01[2357]: segfault at b7f06004 ip b7d6dd6f
> > sp bfb58fe0 error 4 in libc.so.6[b7cfe000+175000] likely on CPU 0
> > (core 0, socket 0)
> > [ 283.996745] Code: 65 c7 07 4b 00 00 00 b8 ff ff ff ff e9 7b fe ff
> > ff 8d b4 26 00 00 00 00 8d 76 00 f3 0f 1e fb 83 ec 1c 8b 44 24 30 85
> > c0 74 1d <8b> 50 04 c7 44 24 0c 00 00 00 00 8b 00 89 54 24 08 89 04 24
> > c1 f8
> > lls/mq_notify/..[ 284.015564] audit: type=1701
> > audit(1680761716.891:32): auid=4294967295 uid=0 gid=0 ses=4294967295
> > subj=kernel pid=2357 comm=\"mq_timedsend01\"
> > exe=\"/opt/ltp/testcases/bin/mq_timedsend01\" sig=11 res=1
> > /utils/mq.h:70: TINFO: receive 1/1 message
> > mq_timedsend01.c:210: TPASS: mq_timedsend() failed expectedly: EFAULT (14)
> > tst_test.c:1581: TBROK: Test killed by SIGSEGV!
> same here
Also broken on glibc:
tst_test.c:1558: TINFO: Timeout per run is 0h 00m 30s
mq_timedsend01.c:153: TINFO: Testing variant: vDSO or syscall with libc spec
mq_timedsend01.c:259: TPASS: mq_timedreceive() returned 0, priority 0, length: 8192
mq_timedsend01.c:259: TPASS: mq_timedreceive() returned 1, priority 0, length: 8192
mq_timedsend01.c:259: TPASS: mq_timedreceive() returned 8192, priority 0, length: 8192
mq_timedsend01.c:259: TPASS: mq_timedreceive() returned 1, priority 32767, length: 8192
mq_timedsend01.c:210: TPASS: mq_timedsend() failed expectedly: EMSGSIZE (90)
mq_timedsend01.c:210: TPASS: mq_timedsend() failed expectedly: EBADF (9)
mq_timedsend01.c:210: TPASS: mq_timedsend() failed expectedly: EBADF (9)
mq_timedsend01.c:210: TPASS: mq_timedsend() failed expectedly: EBADF (9)
mq_timedsend01.c:259: TPASS: mq_timedreceive() returned 16, priority 0, length: 8192
mq_timedsend01.c:210: TPASS: mq_timedsend() failed expectedly: EINVAL (22)
mq_timedsend01.c:210: TPASS: mq_timedsend() failed expectedly: EINVAL (22)
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 1/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 2/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 3/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 4/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 5/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 6/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 7/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 8/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 9/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 10/10 message
mq_timedsend01.c:210: TPASS: mq_timedsend() failed expectedly: EINVAL (22)
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 1/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 2/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 3/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 4/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 5/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 6/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 7/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 8/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 9/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 10/10 message
mq_timedsend01.c:210: TPASS: mq_timedsend() failed expectedly: EINVAL (22)
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 1/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 2/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 3/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 4/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 5/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 6/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 7/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 8/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 9/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 10/10 message
mq_timedsend01.c:210: TPASS: mq_timedsend() failed expectedly: ETIMEDOUT (110)
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 1/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 2/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 3/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 4/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 5/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 6/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 7/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 8/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 9/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 10/10 message
mq_timedsend01.c:210: TPASS: mq_timedsend() failed expectedly: EINTR (4)
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 1/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 2/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 3/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 4/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 5/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 6/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 7/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 8/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 9/10 message
/home/abuild/rpmbuild/BUILD/ltp-20230403.906cbd90/testcases/kernel/syscalls/mq_timedsend/../utils/mq.h:70: TINFO: receive 10/10 message
mq_timedsend01.c:210: TPASS: mq_timedsend() failed expectedly: EFAULT (14)
tst_test.c:1618: TBROK: Test killed by SIGSEGV!
> > ---
> > pread02_64
> > tst_test.c:1524: TINFO: Timeout per run is 0h 05m 00s
> > pread02.[ 319.705083] /dev/zero: Can't open blockdev
> > c:44: TPASS: pread(3, 1024, 0) (null) : ESPIPE (29)
> > tst_test.c:1581: TBROK: Test killed by SIGSEGV!
> This looks like LTP is calling the wrong function here
> for musl: it passes D_FILE_OFFSET_BITS=64 for some tests
> but not others, but on musl you always get the 64-bit
> behavior.
I don't see this error on current master on glibc.
But I see different problem (permission on non-root) on musl chroot even on 64bit:
tst_test.c:112: TBROK: open(/dev/shm/ltp_pread02_64_1577218): EACCES (13)
When running as root it works:
pread02.c:44: TPASS: pread(3, 1024, 0) file descriptor is a PIPE or FIFO : ESPIPE (29)
pread02.c:44: TPASS: pread(5, 1024, -1) specified offset is negative : EINVAL (22)
pread02.c:44: TPASS: pread(6, 1024, 0) file descriptor is a directory : EISDIR (21)
I haven't figured out which packages are needed for 32bit toolchain on Alpine to
test 32 bit.
> > ---
> > recvmmsg01
> > [ 369.451748] recvmmsg01[3821]: segfault at b7cb1004 ip b7dd7413 sp
> > bf992430 error 4 in libc.so.6[b7cda000+175000] likely on CPU 3 (core
> > 3, socket 0)
> > [ 369.466232] Code: 26 00 00 00 00 66 90 f3 0f 1e fb 55 57 56 53 83
> > ec 2c 8b 5c 24 50 8b 44 24 40 8b 54 24 44 8b 4c 24 48 8b 74 24 4c 85
> > db 74 55 <8b> 7b 04 c7 44 24 1c 00 00 00 00 83 ec 08 8b 2b 89 7c 24 14
> > 8b 7c
> > [ 369.485043] audit: type=1701 audit(1680761802.360:44):
> > auid=4294967295 uid=0 gid=0 ses=4294967295 subj=kernel pid=3821
> > comm=\"recvmmsg01\" exe=\"/opt/ltp/testcases/bin/recvmmsg01\" sig=11
> > res=1
> > [ 369.496491] mmap: remap_file_page (3822) uses deprecated
> > remap_file_pages() syscall. See Documentation/mm/remap_file_pages.rst.
> > 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.
> > ---
> > semctl03
> > [ 441.271399] semctl03[6093]: segfault at 0 ip b7e53fc0 sp bf93c0a0
> > error 4 in libc.so.6[b7d56000+175000] likely on CPU 1 (core 1, socket
> > 0)
> > [ 441.284432] Code: 24 5c ff 74 24 5c e8 cf fd ff ff 83 c4 10 85 c0
> > 78 0e ba 04 00 14 00 0f a3 fa 0f 82 ba 00 00 00 83 c4 40 5b 5e 5f c3
> > 8d 76 00 <8b> 03 31 d2 89 e6 66 0f 6e ca 89 04 24 8b 43 04 89 44 24 04
> > 8b 43
> > [ 441.303267] audit: type=1701 audit(1680761874.178:46):
> > auid=4294967295 uid=0 gid=0 ses=4294967295 subj=kernel pid=6093
> > comm=\"semctl03\" exe=\"/opt/ltp/testcases/bin/semctl03\" sig=11 res=1
> > semctl03.c:73: TPASS: semctl() with invalid IPC command : EINVAL (22)
> > tst_test.c:1581: TBROK: Test killed by SIGSEGV!
> time64 again
Works on glibc (32 and 64 bit), works on 64bit musl (under root, again shm
permission problem when testing with non-root).
FYI there are some fixes in master (one glibc specific).
> > semctl04
> > semctl04.c:69: TBROK: semget(1628514830, 10, 600) failed: EEXIST (17)
> > semctl05
> > semctl05.c:54: TBROK: semget(1628514830, 10, 780) failed: EEXIST (17)
> These are probably broken by semctl03 having failed first, and
> they should be fine if you clear out the semaphore first, or
> skip the semctl03 test.
Yes, most likely.
> > ----
> > sigtimedwait01
> > [ 486.624973] sigtimedwait01[6644]: segfault at 5 ip b7d9758f sp
> > bfda7290 error 4 in libc.so.6[b7d80000+175000] likely on CPU 1 (core
> > 1, socket 0)
> > [ 486.639052] Code: c7 03 4b 00 00 00 b8 ff ff ff ff e9 3b fe ff ff
> > 8d b4 26 00 00 00 00 8d 74 26 00 f3 0f 1e fb 83 ec 1c 8b 44 24 28 85
> > c0 74 1d <8b> 50 04 c7 44 24 0c 00 00 00 00 8b 00 89 54 24 08 89 04 24
> > c1 f8
> > [ 486.659213] audit: type=1701 audit(1680761919.535:49):
> > auid=4294967295 uid=0 gid=0 ses=4294967295 subj=kernel pid=6644
> > comm=\"sigtimedwait01\" exe=\"/opt/ltp/testcases/bin/sigtimedwait01\"
> > sig=11 res=1
Broken also on 32bit glibc:
tst_test.c:1618: TBROK: Test killed by SIGSEGV!
> > sigwait.c:344: TPASS: Child exited with expected code
> > tst_test.c:1581: TBROK: Test killed by SIGSEGV!
> sigwait calls sigtimedwait and copies the signal number into
> the provided pointer, so apparently a similar problem. I couldn't
> find the testcase in the ltp sources, only see a sigwait01.c
> not sigwait.c, but that doesn't trigger the bug.
> > ---
> > statfs02
> > statfs02 4 TPASS : expected failure: TEST_ERRNO=EFAULT(14): Bad address
> > statfs02 5 TBROK : tst_sig.c:232: unexpected signal SIGSEGV(11)
> > received (pid = 6728).
> > statfs02 6 TBROK : tst_sig.c:232: Remaining cases broken
> I don't know why musl copes statfs, but this is yet another instance.
> Not time64
Again, converted to the new API, EFAULT fixed.
Kind regards,
Petr
> > statx01
> > statx01.c:138: TPASS: stx_nlink(1) is c[ 833.666410] /dev/zero: Can't
> > open blockdev
> > orrect
> > statx01.c:82: TFAIL: statx.stx_mnt_id(421) is different from
> > mount_id(34280324422697381)[ 833.678950] /dev/zero: Can't open
> > blockdev
> > in /proc/self/mountinfo
> > statx01.c:88: TPASS: /proc/12304/fdinfo/3 mnt_id: = 421
> No idea, possibly some type mismatch between definitions in musl
> and ltp.
> > ---
> > ustat01
> > tst_test.c:1524: TINFO: Timeout per run is 0h 05m 00s
> > ustat01.c:39: TBROK: stat(/,0xbfb96278) failed: EOVERFLOW (75)
> > tst_test.c:1524: TINFO: Timeout per run is 0h 05m 00s
> > ustat02.c:57: TBROK: stat(/,0xbfa11098) failed: EOVERFLOW (75)
> I think the definition of 'struct ustat' in ltp/include/lapi/ustat.h
> is wrong and does not match the kernel. This uses a libc-provided
> 'ino_t', which is probably different from what the kernel expects
> here.
> Arnd
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
Arnd
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
On Thu, Apr 6, 2023, at 14:48, Petr Vorel wrote:
>> On Thu, Apr 6, 2023, at 12:56, Petr Vorel wrote:
>> 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;
> | ^
Sorry, I should have been clearer, the snippet I cited is
from the musl sources, and the __pad access is what causes the
segfault. The fix is to catch the fault on ltp, same as for the
time64 conversions.
Arnd
> On Thu, Apr 6, 2023, at 14:48, Petr Vorel wrote:
> >> On Thu, Apr 6, 2023, at 12:56, Petr Vorel wrote:
> >> 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;
> > | ^
> Sorry, I should have been clearer, the snippet I cited is
> from the musl sources, and the __pad access is what causes the
> segfault. The fix is to catch the fault on ltp, same as for the
> time64 conversions.
Thanks! I've just searched in musl as well, because it didn't make sense to me
it'd be a code for LTP.
"to catch the fault on ltp" I wonder if it's not actually musl bug.
Kind regards,
Petr
> Arnd
On Thu, Apr 6, 2023, at 15:17, Petr Vorel wrote:
>> On Thu, Apr 6, 2023, at 14:48, Petr Vorel wrote:
>> >> On Thu, Apr 6, 2023, at 12:56, Petr Vorel wrote:
> Thanks! I've just searched in musl as well, because it didn't make sense to me
> it'd be a code for LTP.
>
> "to catch the fault on ltp" I wonder if it's not actually musl bug.
No, musl is fine here. The problem is that ltp passes an invalid pointer,
expecting to get -EFAULT from the kernel when that faults in
copy_to_user().
There is nothing wrong with musl sanitizing the data behind that
pointer, but then you get a signal instead of the EFAULT error.
Arnd
Hi!
> > Thanks! I've just searched in musl as well, because it didn't make sense to me
> > it'd be a code for LTP.
> >
> > "to catch the fault on ltp" I wonder if it's not actually musl bug.
>
> No, musl is fine here. The problem is that ltp passes an invalid pointer,
> expecting to get -EFAULT from the kernel when that faults in
> copy_to_user().
>
> There is nothing wrong with musl sanitizing the data behind that
> pointer, but then you get a signal instead of the EFAULT error.
That's actually quite common, usually we fix that by running the test in
a child and treating SEGFAULT as a PASS.
--
Cyril Hrubis
[email protected]
On Thu, 6 Apr 2023 at 16:26, Petr Vorel <[email protected]> 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")
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 will keep you posted with the latest findings.
- Naresh
On Tue, 11 Apr 2023 at 22:15, Naresh Kamboju <[email protected]> wrote:
>
> On Thu, 6 Apr 2023 at 16:26, Petr Vorel <[email protected]> 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.
<Trim>
> > 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")
>
> 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 will keep you posted with the latest findings.
Few quick updates,
Do you see these failures on compat mode ?
Following regressions noticed with LTP version 20230127 on Linux next.
Regressions found on juno-r2-compat:
Regressions found on qemu_arm64-compat:
ltp-syscalls/fcntl34
ltp-syscalls/fcntl36
ltp-syscalls/fcntl34_64
ltp-syscalls/fcntl36_64
tst_test.c:1558: TINFO: Timeout per run is 0h 05m 00s
fcntl34.c:87: TINFO: write to a file inside threads with OFD locks
fcntl34.c:33: TINFO: spawning '18' threads
tst_kernel.c:87: TINFO: uname.machine=aarch64 kernel is 64bit
fcntl34.c:63: TBROK: fcntl(4, F_OFD_SETLKW, { 1, 0, 0, 1, 0 }): EINVAL (22)
tst_test.c:1558: TINFO: Timeout per run is 0h 05m 00s
fcntl34.c:87: TINFO: write to a file inside threads with OFD locks
fcntl34.c:33: TINFO: spawning '18' threads
tst_kernel.c:87: TINFO: uname.machine=aarch64 kernel is 64bit
fcntl34.c:63: TBROK: fcntl(4, F_OFD_SETLKW, { 1, 0, 0, 1, 0 }): EINVAL (22)
tst_test.c:1558: TINFO: Timeout per run is 0h 05m 00s
fcntl36.c:288: TINFO: OFD read lock vs OFD write lock
tst_kernel.c:87: TINFO: uname.machine=aarch64 kernel is 64bit
fcntl36.c:166: TBROK: fcntl(3, F_OFD_SETLKW, { 0, 0, 0, 4096, 0 }): EINVAL (22)
tst_test.c:1558: TINFO: Timeout per run is 0h 05m 00s
fcntl36.c:288: TINFO: OFD read lock vs OFD write lock
tst_kernel.c:87: TINFO: uname.machine=aarch64 kernel is 64bit
fcntl36.c:166: TBROK: fcntl(3, F_OFD_SETLKW, { 0, 0, 0, 4096, 0 }): EINVAL (22)
Test details links,
https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230411/testrun/16168516/suite/ltp-syscalls/test/fcntl36/history/
https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230411/testrun/16168516/suite/ltp-syscalls/test/fcntl34/history/
https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230411/testrun/16168516/suite/ltp-syscalls/test/fcntl36/log
Steps to reproduce:
# To install tuxrun on your system globally:
# sudo pip3 install -U tuxrun==0.41.0
#
# See https://tuxrun.org/ for complete documentation.
tuxrun \
--runtime podman \
--device qemu-arm64 \
--kernel https://storage.tuxsuite.com/public/linaro/lkft/builds/2OGsEcyUv1ZWPkcY6bowUEt67EK/Image.gz
\
--modules https://storage.tuxsuite.com/public/linaro/lkft/builds/2OGsEcyUv1ZWPkcY6bowUEt67EK/modules.tar.xz
\
--rootfs https://storage.tuxsuite.com/public/linaro/lkft/oebuilds/2OFRZRfcnhLXEnzmi2qNYuD7o3k/images/am57xx-evm/lkft-tux-image-am57xx-evm-20230410193023.rootfs.ext4.gz
\
--parameters SKIPFILE=skipfile-lkft.yaml \
--parameters SHARD_NUMBER=10 \
--parameters SHARD_INDEX=2 \
--image docker.io/lavasoftware/lava-dispatcher:2023.01.0020.gc1598238f \
--tests ltp-syscalls \
--timeouts boot=30 ltp-syscalls=50
--
Linaro LKFT
https://lkft.linaro.org
> On Thu, 6 Apr 2023 at 16:26, Petr Vorel <[email protected]> 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
Hello!
On Tue, 11 Apr 2023 at 16:08, Petr Vorel <[email protected]> wrote:
>
> > On Thu, 6 Apr 2023 at 16:26, Petr Vorel <[email protected]> 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.
Thanks for looking into this! Greetings!
Daniel Díaz
[email protected]
> Hello!
> On Tue, 11 Apr 2023 at 16:08, Petr Vorel <[email protected]> wrote:
> > > On Thu, 6 Apr 2023 at 16:26, Petr Vorel <[email protected]> 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
> [email protected]