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-11589 Lustre <p>After a filesystem corruption event and e2fsck 1.44.3.wc1 running to repair it, the server keeps crashing with the following error:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>Lustre: nbp13-OST0008: trigger OI scrub by RPC for the [0x100080000:0x217edd:0x0] with flags 0x4a, rc = 0 ------------[ cut here ]------------ kernel BUG at /tmp/rpmbuild-lustre-jlan-ItUrr9b3/BUILD/lustre-2.10.5/ldiskfs/ldiskfs.h:1907! invalid opcode: 0000 [#1] SMP CPU: 5 PID: 11348 Comm: lfsck Tainted: G OE ------------ 3.10.0-693.21.1.el7.20180508.x86_64.lustre2105 #1 RIP: 0010:[&lt;ffffffffa10fbd04&gt;] [&lt;ffffffffa10fbd04&gt;] ldiskfs_rec_len_to_disk.part.9+0x4/0x10 [ldiskfs] Call Trace: htree_inlinedir_to_tree+0x445/0x450 [ldiskfs] ldiskfs_htree_fill_tree+0x137/0x2f0 [ldiskfs] ldiskfs_readdir+0x61c/0x850 [ldiskfs] osd_ldiskfs_it_fill+0xbe/0x260 [osd_ldiskfs] osd_it_ea_load+0x37/0x100 [osd_ldiskfs] lfsck_open_dir+0x11c/0x3a0 [lfsck] lfsck_master_oit_engine+0x9a2/0x1190 [lfsck] lfsck_master_engine+0x8f6/0x1360 [lfsck] kthread+0xd1/0xe0 </pre> </div></div> LU-11589

kernel BUG at ldiskfs.h:1907!

Technical task LU-5603 Critical Open Unresolved WC Triage Andreas Dilger easy ldiskfs Wed, 31 Oct 2018 22:40:05 +0000 Thu, 20 Jan 2022 23:54:48 +0000 Lustre 2.10.5 0 3 <p>Making this a separate ticket, since it looks like it is a bug in the <tt>inline_data</tt> handling in ldiskfs. The code in question is:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> <span class="code-keyword">static</span> inline __le16 ldiskfs_rec_len_to_disk(unsigned len, unsigned blocksize) { <span class="code-keyword">if</span> ((len &gt; blocksize) || (blocksize &gt; (1 &lt;&lt; 18)) || (len &amp; 3)) BUG(); #<span class="code-keyword">if</span> (PAGE_CACHE_SIZE &gt;= 65536) <span class="code-keyword">if</span> (len &lt; 65536) <span class="code-keyword">return</span> cpu_to_le16(len); <span class="code-keyword">if</span> (len == blocksize) { <span class="code-keyword">if</span> (blocksize == 65536) <span class="code-keyword">return</span> cpu_to_le16(LDISKFS_MAX_REC_LEN); <span class="code-keyword">else</span> <span class="code-keyword">return</span> cpu_to_le16(0); } <span class="code-keyword">return</span> cpu_to_le16((len &amp; 65532) | ((len &gt;&gt; 16) &amp; 3)); #<span class="code-keyword">else</span> <span class="code-keyword">return</span> cpu_to_le16(len); #endif } </pre> </div></div> <p>which has <tt>BUG()</tt> as an error handling mechanism. We should never BUG() when processing data from disk. In this case, the problem is that the calling convention of <tt>ldiskfs_rec_len_to_disk()</tt> means there is no way to return an error to the caller. That means we can only pass verified values to this function, or change the function to take <tt>rec_len</tt> as an argument and return 0 or an error code.</p> <p>I think the real issue here is in the ext4-data-in-dirent.patch:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> @@ -1348,7 +1348,7 @@ <span class="code-object">int</span> htree_inlinedir_to_tree(struct file fake.name_len = 1; strcpy(fake.name, <span class="code-quote">"."</span>); fake.rec_len = ext4_rec_len_to_disk( - EXT4_DIR_REC_LEN(fake.name_len), + EXT4_DIR_REC_LEN(&amp;fake), inline_size); ext4_set_de_type(inode-&gt;i_sb, &amp;fake, S_IFDIR); de = &amp;fake; @@ -1358,7 +1358,7 @@ <span class="code-object">int</span> htree_inlinedir_to_tree(struct file fake.name_len = 2; strcpy(fake.name, <span class="code-quote">".."</span>); fake.rec_len = ext4_rec_len_to_disk( - EXT4_DIR_REC_LEN(fake.name_len), + EXT4_DIR_REC_LEN(&amp;fake), inline_size); ext4_set_de_type(inode-&gt;i_sb, &amp;fake, S_IFDIR); de = &amp;fake;</pre> </div></div> <p>The new EXT4_DIR_REC_LEN introduced by dirdata calls ext4_get_dirent_data_len(de), in this case the de is just on the stack and contains garbage, so the BUG() was triggered when we pass the value to ext4_rec_len_to_disk.</p> <p>We should use __EXT4_DIR_REC_LEN(fake.name_len) instead.</p> <p>So in this case, the BUG() seems warranted...</p> Cloners LU-11584 Related LU-5603 Development Rank 1|i005fb: Rank (Obsolete) 9223372036854775807