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-4472 Lustre <p>This issue was created by maloo for Nathaniel Clark &lt;nathaniel.l.clark@intel.com&gt;</p> <p>This issue relates to the following test suite run: <a href="http://maloo.whamcloud.com/test_sets/a7c7a94c-6f50-11e3-ad93-52540035b04c" class="external-link" target="_blank" rel="nofollow noopener">http://maloo.whamcloud.com/test_sets/a7c7a94c-6f50-11e3-ad93-52540035b04c</a>.</p> <p>The sub-test test_8 failed with the following error:</p> <blockquote> <p>test failed to respond and timed out</p></blockquote> <p>Info required for matching: sanity-quota 8</p> <p>Client console log:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>12:07:36:LustreError: 28141:0:(mdc_request.c:1237:mdc_page_locate()) ASSERTION( *start &lt;= *hash ) failed: start = 0x1,end = 0xfffffffffffffffe,hash = 0x0 12:07:36:LustreError: 28141:0:(mdc_request.c:1237:mdc_page_locate()) LBUG 12:07:36:Pid: 28141, comm: rm 12:07:36: 12:07:36:Call Trace: 12:07:36: [&lt;ffffffffa1325895&gt;] libcfs_debug_dumpstack+0x55/0x80 [libcfs] 12:07:36: [&lt;ffffffffa1325e97&gt;] lbug_with_loc+0x47/0xb0 [libcfs] 12:07:36: [&lt;ffffffffa03d3443&gt;] mdc_read_page+0x853/0x920 [mdc] 12:07:36: [&lt;ffffffffa0580320&gt;] ? ll_md_blocking_ast+0x0/0x810 [lustre] 12:07:36: [&lt;ffffffff81281436&gt;] ? vsnprintf+0x336/0x5e0 12:07:36: [&lt;ffffffffa03d3577&gt;] mdc_read_entry+0x67/0x390 [mdc] 12:07:36: [&lt;ffffffffa1832f0d&gt;] lmv_read_entry+0x3fd/0xa70 [lmv] 12:07:36: [&lt;ffffffffa053a97c&gt;] ll_dir_entry_start+0xbc/0x330 [lustre] 12:07:36: [&lt;ffffffffa0580320&gt;] ? ll_md_blocking_ast+0x0/0x810 [lustre] 12:07:36: [&lt;ffffffffa053c0c0&gt;] ? ll_update_inode_size+0x0/0x40 [lustre] 12:07:36: [&lt;ffffffff8109f641&gt;] ? in_group_p+0x31/0x40 12:07:36: [&lt;ffffffffa053c693&gt;] ll_dir_read+0x83/0x230 [lustre] 12:07:36: [&lt;ffffffffa057e13d&gt;] ? ll_i2gids+0x3d/0xd0 [lustre] 12:07:36: [&lt;ffffffff81196550&gt;] ? filldir+0x0/0xe0 12:07:36: [&lt;ffffffffa053c95d&gt;] ll_readdir+0x11d/0x3b0 [lustre] 12:07:36: [&lt;ffffffff81196550&gt;] ? filldir+0x0/0xe0 12:07:36: [&lt;ffffffff81196550&gt;] ? filldir+0x0/0xe0 12:07:36: [&lt;ffffffff811967d0&gt;] vfs_readdir+0xc0/0xe0 12:07:36: [&lt;ffffffff81196959&gt;] sys_getdents+0x89/0xf0 12:07:36: [&lt;ffffffff8100b072&gt;] system_call_fastpath+0x16/0x1b 12:07:36: </pre> </div></div> LU-4472

sanity-quota test_8: mdc_page_locate() ASSERTION( *start <= *hash )

Bug Blocker Resolved Fixed Nathaniel Clark Maloo MB Fri, 10 Jan 2014 19:30:21 +0000 Thu, 27 Feb 2014 18:20:35 +0000 Thu, 27 Feb 2014 18:20:35 +0000 Lustre 2.6.0 Lustre 2.6.0 0 8 <p>Remove offending ASSERT</p> <p><a href="http://review.whamcloud.com/8821" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/8821</a></p> <p>So the issue appears to be hash_x_index()</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"><span class="code-keyword">static</span> inline __u64 hash_x_index(__u64 hash, <span class="code-object">int</span> hash64) { <span class="code-keyword">if</span> (BITS_PER_LONG == 32 &amp;&amp; hash64) hash &gt;&gt;= 32; /* save hash 0 as index 0 because otherwise we'll save it at * page index end (~0UL) and it causes truncate_inode_pages_range() * to loop forever. */ <span class="code-keyword">return</span> ~0ULL - (hash + !hash); } </pre> </div></div> <p>The problem appears to be hash_x_index(0) == hash_x_index(1) == -2ULL, according to the comment it would appear that the indent of <a href="http://review.whamcloud.com/8237" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/8237</a> (and kernel patch <a href="https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=363090e74f3865c589f4026b40865596b0212f90" class="external-link" target="_blank" rel="nofollow noopener">363090e</a>) would be hash_x_index(0) == 0ULL</p> <p>I think the comment in hash_x_index() is outdated. That was the original proposal, but it means that hash==0 went from 0xffffffffffffffff to 0, which is strange. Instead, it just puts it into the same bucket as hash==1 where one would expect it to be.</p> <p>It may be that the LASSERT() needs to be fixed to handle this one case?</p> <p>More instances on master branch:<br/> <a href="https://maloo.whamcloud.com/test_sets/81732fd2-887d-11e3-b26e-52540035b04c" class="external-link" target="_blank" rel="nofollow noopener">https://maloo.whamcloud.com/test_sets/81732fd2-887d-11e3-b26e-52540035b04c</a><br/> <a href="https://maloo.whamcloud.com/test_sets/1610607e-887e-11e3-b26e-52540035b04c" class="external-link" target="_blank" rel="nofollow noopener">https://maloo.whamcloud.com/test_sets/1610607e-887e-11e3-b26e-52540035b04c</a></p> <p>Patch landed to Master. Please reopen if this problem persists.</p> Development Rank 1|hzwcnb: Rank (Obsolete) 12252 Severity