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-3717 Lustre <p>Hit a kernel panic while trying to test the new file handle syscalls (name_to_handle_at()/open_by_handle_at())</p> <p>To reproduce follow the following steps:<br/> 1) Apply patch (<a href="http://review.whamcloud.com/#/c/7247/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/7247/</a>). This patch adds a new file lustre/tests/check_fhandle_syscalls.c<br/> 2) Compile lustre client<br/> 3) Setup lustre (sh lustre/tests/llmount.sh)<br/> 4) Create a temporary file in FS (echo "testing new syscalls" &gt; /mnt/lustre/temp_file)<br/> 5) Run the test utility as follows:<br/> cd lustre/tests;<br/> ./check_fhandle_syscalls temp_file /mnt/lustre</p> <p>The following is the stack trace of the panic:</p> <p>crash&gt; bt -l<br/> PID: 2139 TASK: ffff880011495c40 CPU: 0 COMMAND: "check_fhandle_s"<br/> #0 <span class="error">&#91;ffff8800115cbc90&#93;</span> machine_kexec at ffffffff8103e9a5<br/> /usr/src/debug/kernel-3.6.fc18/linux-3.6.10-4.fc18.x86_64/arch/x86/kernel/machine_kexec_64.c: 339<br/> #1 <span class="error">&#91;ffff8800115cbd00&#93;</span> crash_kexec at ffffffff810c4118<br/> /usr/src/debug/kernel-3.6.fc18/linux-3.6.10-4.fc18.x86_64/kernel/kexec.c: 1100<br/> #2 <span class="error">&#91;ffff8800115cbdd0&#93;</span> panic at ffffffff816198e2<br/> /usr/src/debug/kernel-3.6.fc18/linux-3.6.10-4.fc18.x86_64/arch/x86/include/asm/smp.h: 95<br/> #3 <span class="error">&#91;ffff8800115cbe50&#93;</span> lbug_with_loc at ffffffffa0418e5b <span class="error">&#91;libcfs&#93;</span><br/> #4 <span class="error">&#91;ffff8800115cbe90&#93;</span> ll_encode_fh at ffffffffa0961b75 <span class="error">&#91;lustre&#93;</span><br/> #5 <span class="error">&#91;ffff8800115cbed0&#93;</span> exportfs_encode_fh at ffffffff81264ce4<br/> /usr/src/debug/kernel-3.6.fc18/linux-3.6.10-4.fc18.x86_64/fs/exportfs/expfs.c: 361<br/> #6 <span class="error">&#91;ffff8800115cbf10&#93;</span> sys_name_to_handle_at at ffffffff811e8f36<br/> /usr/src/debug/kernel-3.6.fc18/linux-3.6.10-4.fc18.x86_64/fs/fhandle.c: 52<br/> #7 <span class="error">&#91;ffff8800115cbf80&#93;</span> system_call_fastpath at ffffffff8162bae9<br/> /usr/src/debug/kernel-3.6.fc18/linux-3.6.10-4.fc18.x86_64/arch/x86/kernel/entry_64.S: 532<br/> RIP: 00000030828f309a RSP: 00007fff2f0d94c8 RFLAGS: 00010202<br/> RAX: 000000000000012f RBX: ffffffff8162bae9 RCX: 00007fff2f0d9578<br/> RDX: 0000000000720010 RSI: 00007fff2f0da853 RDI: 0000000000000003<br/> RBP: 00007fff2f0d95b0 R8: 0000000000000400 R9: 616e20676e696c6c<br/> R10: 00007fff2f0d9578 R11: 0000000000000202 R12: 0000000000000000<br/> R13: 0000000000000000 R14: 00007fff2f0d9690 R15: 00000000004008f0<br/> ORIG_RAX: 000000000000012f CS: 0033 SS: 002b</p> LU-3717

Kernel panic in ll_encode_fh() while testing file handle syscalls on FC18 client

Bug Major Resolved Duplicate Jian Yu Swapnil Pimpale Wed, 7 Aug 2013 08:35:42 +0000 Wed, 4 Dec 2013 01:24:08 +0000 Wed, 4 Dec 2013 01:22:39 +0000 Lustre 2.4.1 Lustre 2.5.0 0 9 <p>The LBUG is due to ll_inode2fid() wishing that the inode is not NULL, and it's somehow passed in as NULL to ll_encode_fh()<br/> So we need to check for that and take some appropriate action.</p> <p>On FC18 client node, I set panic_on_lbug=0 and got the lctl debug log as follows:</p> <div class="panel" style="border-width: 1px;"><div class="panelContent"> <p>00000080:00000001:2.0:1382612125.266070:0:21111:0:(llite_nfs.c:187:ll_encode_fh()) Process entered<br/> 00000080:00000040:2.0:1382612125.266071:0:21111:0:(llite_nfs.c:191:ll_encode_fh()) <font color="green">encoding for (144115205255725059,<span class="error">&#91;0x200000400:0x3:0x0&#93;</span>) maxlen=32 minlen=32</font><br/> 00000080:00040000:2.0:1382612125.266073:0:21111:0:(llite_internal.h:1166:ll_inode2fid()) ASSERTION( inode != ((void *)0) ) failed:<br/> 00000080:00040000:2.0:1382612125.277251:0:21111:0:(llite_internal.h:1166:ll_inode2fid()) LBUG</p> </div></div> <p>In ll_encode_fh():</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"><span class="code-keyword">static</span> <span class="code-object">int</span> ll_encode_fh(struct inode *inode, __u32 *fh, <span class="code-object">int</span> *plen, struct inode *parent) { <span class="code-comment">//...... </span> CDEBUG(D_INFO, <span class="code-quote">"encoding <span class="code-keyword">for</span> (%lu,"</span>DFID<span class="code-quote">") maxlen=%d minlen=%d\n"</span>, inode-&gt;i_ino, PFID(ll_inode2fid(inode)), *plen, (<span class="code-object">int</span>)sizeof(struct lustre_nfs_fid)); <span class="code-comment">//...... </span> nfs_fid-&gt;lnf_child = *ll_inode2fid(inode); nfs_fid-&gt;lnf_parent = *ll_inode2fid(parent); &lt;------ parent was NULL, which caused the ASSERTION failure <span class="code-comment">//...... </span>} </pre> </div></div> <p>Need to dig out why "parent" passed from exportfs_encode_fh() to ll_encode_fh() was NULL.</p> <p>In Linux kernel 3.6.10-4 used by FC18, exportfs_encode_fh() was called from do_sys_name_to_handle() as follows:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"><span class="code-keyword">static</span> <span class="code-object">long</span> do_sys_name_to_handle(struct path *path, struct file_handle __user *ufh, <span class="code-object">int</span> __user *mnt_id) { <span class="code-comment">//...... </span> <span class="code-comment">/* we ask <span class="code-keyword">for</span> a non connected handle */</span> retval = exportfs_encode_fh(path-&gt;dentry, (struct fid *)handle-&gt;f_handle, &amp;handle_dwords, 0); &lt;------ Here, 0 was passed to exportfs_encode_fh(). <span class="code-comment">//...... </span>} </pre> </div></div> <p>While in exportfs_encode_fh(), the codes are:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"><span class="code-object">int</span> exportfs_encode_fh(struct dentry *dentry, struct fid *fid, <span class="code-object">int</span> *max_len, <span class="code-object">int</span> connectable) { <span class="code-comment">//...... </span> struct inode *inode = dentry-&gt;d_inode, *parent = NULL; <span class="code-keyword">if</span> (connectable &amp;&amp; !S_ISDIR(inode-&gt;i_mode)) { &lt;------ Here, connectable was 0. p = dget_parent(dentry); <span class="code-comment">//...... </span> parent = p-&gt;d_inode; } <span class="code-keyword">if</span> (nop-&gt;encode_fh) error = nop-&gt;encode_fh(inode, fid-&gt;raw, max_len, parent); &lt;------ Here, parent was NULL. <span class="code-comment">//...... </span>} </pre> </div></div> <p>So, exportfs_encode_fh() finally passed "parent" parameter as NULL to ll_encode_fh().<br/> The ll_encode_fh() should check the "parent" value before running ll_inode2fid(). I'll upload a patch.</p> <p>Patch for master branch is in <a href="http://review.whamcloud.com/8072" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/8072</a>.</p> <p>It's a similar issue to <a href="https://jira.whamcloud.com/browse/LU-4231" title="NFS reexport leads to LBUG in mainline 3.12 client" class="issue-link" data-issue-key="LU-4231"><del>LU-4231</del></a>. I have provided other patch <a href="http://review.whamcloud.com/8347" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/8347</a> that more accurate distinguish cases where parent is NULL and not.</p> <p>Just tested the <a href="http://review.whamcloud.com/8347" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/8347</a> patch and I get this:</p> <p><span class="error">&#91;root@spoon46 ~&#93;</span># /usr/lib64/lustre/tests/check_fhandle_syscalls temp-file /lustre/barry/<br/> fh_bytes: 32<br/> fh_type: 151<br/> fh_data: 0 4 0 0 2 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 <br/> check_fhandle_syscalls test Passed!</p> <p>It appears to work correctly.</p> <p>The patch in <a href="http://review.whamcloud.com/8347" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/8347</a> resolves the failure. Let's close this ticket as a duplicate of <a href="https://jira.whamcloud.com/browse/LU-4231" title="NFS reexport leads to LBUG in mainline 3.12 client" class="issue-link" data-issue-key="LU-4231"><del>LU-4231</del></a>.</p> Duplicate LU-4231 Related LU-3344 Development Rank 1|hzvxc7: Rank (Obsolete) 9574 Severity