Hi!
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:
- a bug in LTP, testing something that is not guaranteed to be reliable, or maybe not on all file systems.
- an old bug in the kernel, possibly fixed in newer versions
- 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.
The assertion that fail runs several threads where:
First half of them are writers where each of these loops:
* lock region in a file with posix write lock * write to the region * unlock it
While the second half loops concurently (time and file offset vise):
* lock region with read ofd lock * read the region, expects it to be consistent block vise * unlock it
As far as I can tell this is supposed to be supported combination
Also I'm not aware of any kernel bugs in this area either, when we add a bug reproducer to LTP we include kernel commit hash in the top level comment in the testcase, which isn't the case here. Maybe Xiong Zhou can elaborate.
What filesystem is this testcase running against, i.e. what is in TMPDIR (defaults to /tmp) and what is mounted under that directory? We are running this test in SUSE against several kernel versions since it was introduced in the git repository and we never seen a failure, we are running it mostly against Btrfs though.