https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-4713 Lustre <p>This issue was created by maloo for sarah &lt;sarah@whamcloud.com&gt;</p> <p>This issue relates to the following test suite run: <a href="http://maloo.whamcloud.com/test_sets/a67ae282-a01c-11e3-ab91-52540035b04c" class="external-link" target="_blank" rel="nofollow noopener">http://maloo.whamcloud.com/test_sets/a67ae282-a01c-11e3-ab91-52540035b04c</a>.</p> <p>The sub-test test_237 failed with the following error:</p> <blockquote> <p>check_fhandle_syscalls failed</p></blockquote> <p>test log</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>== sanity test 237: Verify name_to_handle_at/open_by_handle_at syscalls ============================== 17:55:21 (1393466121) name_by_handle_at(f237.sanity) error: Bad file descriptor sanity test_237: @@@@@@ FAIL: check_fhandle_syscalls failed </pre> </div></div> server: lustre-master build # 1911 RHEL6 ldiskfs<br/> client is SLES11 SP3 LU-4713

Failure on test suite sanity test_237: check_fhandle_syscalls failed

Bug Minor Resolved Fixed Bob Glossman Maloo patch Wed, 5 Mar 2014 07:37:22 +0000 Wed, 14 May 2014 14:11:09 +0000 Wed, 14 May 2014 14:11:09 +0000 Lustre 2.6.0 Lustre 2.6.0 0 7 <p>Swapnil, could you please take a look at this bug, since it relates to the open_by_handle() code/test that you added.</p> <p>Is there a way to reproduce this?</p> <p>As far as I can tell this is easy to reproduce. Seen with any sles11sp3 client. In sles11sp3 with default kernel .config lustre is built with '#define HAVE_FHANDLE_SYSCALLS 1' and '#undef HAVE_FHANDLE_GLIBC_SUPPORT'. The test program check_fhandle_syscalls seems to build OK, but always returns an error when called.</p> <p>The test failed with the following reason:<br/> name_by_handle_at(f237.sanity) error: Bad file descriptor</p> <p>I don't think it failed because HAVE_FHANDLE_SYSCALLS is defined and HAVE_FHANDLE_GLIBC_SUPPORT is not. Because in that case we explicitly define struct file_handle, __NR_name_to_handle_at and __NR_open_by_handle_at.</p> <p>test_237 does the following:<br/> echo "Test file_handle syscalls" &gt; $DIR/$tfile<br/> without checking whether the write succeeded. I think we should add a check here.</p> <p>Patch with the above check: <a href="http://review.whamcloud.com/#/c/10088/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/10088/</a></p> <p>test run with your added check still fails and doesn't report failure in the write. it still reports what looks like a failure in check_fhandle_syscalls: "name_by_handle_at(f237.sanity) error: Bad file descriptor"</p> <p>I suspect the local definitions in the test program that are used in the case of !defined(HAVE_FHANDLE_GLIBC_SUPPORT) &amp;&amp; defined(HAVE_FHANDLE_SYSCALLS) don't exactly match the definitions in the underlying kernel.</p> <p>Since in Centos where the feature doesn't exist the test program always just reports success without really doing anything and in SLES where the feature does exist the test always fails, I'm going to just disable the test for now. In its current state this test isn't adding any value and it's just making SLES test runs fail.</p> <p>patch to disable the test<br/> <a href="http://review.whamcloud.com/10105" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/10105</a></p> <p>That is strange. The test should succeed on systems with kernel fhandle and lacking glibc support. That is the test setup I worked with. What does the config logs show for your SP3 system? Is HAVE_FHANDLE_GLIBC_SUPPORT set when it shouldn't be?</p> <p>no, I'm seeing HAVE_FHANDLE_GLIBC_SUPPORT #undef'ed. I can manually run check_fhandle_syscalls and it fails every time. As I said I suspect the internal definitions in the test program don't match the real definitions in the underlying kernel. That's the only think I can think of that might be a cause.</p> <p>Just as speculation I tried replacing the local definitions of syscall numbers and struct file_handle with ones from SLES #include files. I'm guessing the ones that are in there now are from RHEL instances. If I do that then the test passes. I think this confirms my theory about the local definitions in the test program not matching the underlying kernel.</p> <p>However there's still a problem. I can't figure out how to define the correct syscall numbers for all builds. It seems to vary based on the arch type.</p> <p>In arch/x86/include/asm/unistd_64.h it's:</p> <p>#define __NR_name_to_handle_at 303<br/> #define __NR_open_by_handle_at 304</p> <p>while in arch/x86/include/asm/unistd_32.h it's:</p> <p>#define __NR_name_to_handle_at 341<br/> #define __NR_open_by_handle_at 342</p> <p>and in include/asm-generic/unistd.h it's:</p> <p>#define __NR_name_to_handle_at 264<br/> #define __NR_open_by_handle_at 265</p> <p>Since I'm on x86_64 I hard coded the values from unistd_64.h and it worked for me, but that's hardly a production worthy general solution.</p> <p>I wonder if their is a way to do header magic to make this work.</p> <p>It seems likely there is a way to do header magic to get what is needed, but I can't figure out how. The only method I can come up with so far is a horrible, ad-hoc series of #if tests hard coded in. Pretty sure that's not the way to go.</p> <p>fix for test program:<br/> <a href="http://review.whamcloud.com/10189" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/10189</a></p> <p>I did the horrible sequence of #if's as I couldn't come up with a better scheme.<br/> Please add review comments if you have a better idea.</p> <p>Patch landed to master. Ticket can be closed and be reopened if needed.</p> <p>Landed for 2.6</p> Development Rank 1|hzwgrz: Rank (Obsolete) 12955 Severity