On Mon, Oct 16, 2017 at 3:04 PM, Naresh Kamboju naresh.kamboju@linaro.org wrote:
On Mon, Oct 16, 2017 at 09:48:30AM +0000, Linaro QA wrote:
Here is the log for the failure test case.
fcntl36.c:303: INFO: OFD read lock vs OFD write lock fcntl36.c:381: PASS: Access between threads synchronized fcntl36.c:303: INFO: OFD write lock vs POSIX write lock fcntl36.c:381: PASS: Access between threads synchronized fcntl36.c:303: INFO: OFD read lock vs POSIX write lock fcntl36.c:205: FAIL: Unexpected data offset 12304 value 9 fcntl36.c:205: FAIL: Unexpected data offset 13568 value 47 fcntl36.c:303: INFO: OFD write lock vs POSIX read lock fcntl36.c:381: PASS: Access between threads synchronized fcntl36.c:303: INFO: OFD write lock vs OFD write lock fcntl36.c:381: PASS: Access between threads synchronized fcntl36.c:303: INFO: OFD r/w lock vs POSIX write lock fcntl36.c:381: PASS: Access between threads synchronized fcntl36.c:303: INFO: OFD r/w lock vs POSIX read lock fcntl36.c:381: PASS: Access between threads synchronized Summary: passed 6 failed 2 skipped 0 warnings 0
Linux version 4.4.92 (buildslave@x86-64-08) (gcc version 6.2.1 20161016 (Linaro GCC 6.2-2016.11) ) #1 SMP Thu Oct 12 10:59:44 UTC 2017
LAVA job id: https://lkft.validation.linaro.org/scheduler/job/46680#L2847
Bug reported for this failure please refer this link. LKFT: 4.4: X15: LTP syscall test case fcntl36.c:205: FAIL: Unexpected data offset 12304 value 9 https://bugs.linaro.org/show_bug.cgi?id=3339
This bug is not consistence, I have re tested fcntl36.
- test PASS in independent run "./fcntl36"
- test FAIL with "strace ./fcntl36"
Ok. I have cross-checked this with the contents of Linux 4.4.92, nothing got merged in *this* release that is likely to be related to the particular problem found here.
The most likely possible causes then are:
1. a bug in LTP, testing something that is not guaranteed to be reliable, or maybe not on all file systems. 2. an old bug in the kernel, possibly fixed in newer versions 3. a regression introduced in an earlier v4.4.y snapshot but not caught by the unreliable test
I see that the test case in question is relatively new, fcntl36.c was only added in LTP on September 1 2017, so this might be a previously unknown problem with the test case, or it might be known bug that the test case was added to find. I've added Xiong Zhou and Cyril Hrubis to Cc, they were both involved in adding the test case to LTP and may have more information.
Arnd