gramine
gramine copied to clipboard
gramineproject
bind01 & select01 fails with updated ltp commit
Description of the problem
Gramine is on older LTP commit which makes this test passes, but with LTP commit 433b6cf7ade3d5e3bd4b85ac89b164c53312e65a bind01 and select01 are failing
https://github.com/linux-test-project/ltp/tree/433b6cf7ade3d5e3bd4b85ac89b164c53312e65a on Oct 15, 2021 bind01: 5th testcase fails, return EACCES error instead of EADDRNOTAVAIL select01: select() with regular file timed out select03
Steps to reproduce
Checkout LTP commit 433b6cf7ade3d5e3bd4b85ac89b164c53312e65a
Expected results
bind01:
TPASS: non-local address successful
Select01:
TPASS: select() with regular file returned 1
TPASS: readfds bit 3 is set
Actual results
bind01
TFAIL: non-local address expected EADDRNOTAVAIL: EACCES (13)
select01:
TFAIL: select() with regular file timed out
Gramine commit hash:
64abe304efc32f1380d176c4ca041148040af277
Gramine commit hash:
Latest Master
Which commit is "latest master"? You are aware that next week this will be a completely different one? ;)
I confirm that the newer LTP fails in these tests.
Is it time for Gramine to move to a newer LTP, and fix such problems along the way? @mkow @boryspoplawski @woju ?
Adding test clock_gettime01 to the list because updated test uses /proc/self/stat which is not supported by Gramine.
@anjalirai-intel /proc/self/stat is supported by Gramine (albeit most fields are dummy zeroes)
@boryspoplawski When I run this test, this test failed with below error
[0.013] /home/intel/jenkins/workspace/anjali_gnative_ubuntu/gramine/libos/test/ltp/ltp_src/lib/tst_test.c:1362: TINFO: Timeout per run is 0h 00m 10s
[0.037] /home/intel/jenkins/workspace/anjali_gnative_ubuntu/gramine/libos/test/ltp/ltp_src/testcases/kernel/syscalls/clock_gettime/clock_gettime01.c:78: TINFO: Testing variant: vDSO or syscall with libc spec
[10.047] Test timeouted, sending SIGKILL!
[15.051] Test timeouted, sending SIGKILL!
[20.056] Test timeouted, sending SIGKILL!
[25.062] Test timeouted, sending SIGKILL!
@boryspoplawski Previously we had proc mounted in our manifest files because initially support was not there, but now we have removed proc from our manifest files, this test failed and we were under assumption that /proc/self/stat is not supported
It's possible that the test looks at state fields to check whether the subprocess is still running
Is it something that could be fixed or will it be a Graphene Limitation
Some limited additional options could be possibly implemented (maybe enough for LTP), but there are no plans atm for implementing it
Yes, sure. Even if limited implementation that could help this testcase will also be beneficial