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-7853 Lustre <p>Replaced bitfields viz. lq_dirty, lq_same_space, and lq_reset to named bits and use atomic functions. As those are more safe.</p> LU-7853

Fixes bitfield in lod qos code

Bug Minor Resolved Fixed Jian Yu Rahul Deshmukh patch Mon, 7 Mar 2016 17:28:10 +0000 Thu, 15 Jul 2021 20:57:03 +0000 Fri, 26 Feb 2021 21:15:24 +0000 Lustre 2.15.0 0 6 <p>Rahul Deshmukh (rahul.deshmukh@seagate.com) uploaded a new patch: <a href="http://review.whamcloud.com/18812" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/18812</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-7853" title="Fixes bitfield in lod qos code" class="issue-link" data-issue-key="LU-7853"><del>LU-7853</del></a> lod: Fixes bitfield in lod qos code<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 3f153f8b4a365b801934d1de843389e4e51a90c8</p> <p>So were tyou hittign any real problems with the code that you feel you needed the atomic bit operations?</p> <p>Yes, problem was hit on older code i.e. version 2.5 and it was seen for lq_dirty. So as a fixed other bitfield with those. Actually lq_dirty is not present in latest code but still to be safer side ported this patch.</p> <p>I agree with Oleg that "more safe" doesn't provide justification for landing the patch. I can imagine that there is some problem with these bitfields in the code, though it seems <tt>lq_rw_sem</tt> is held when <tt>lq_dirty</tt> and <tt>lq_same_space</tt> are accessed and modified, except in <tt>lod_qos_priofree_seq_write()</tt> and <tt>lod_qos_thresholdrr_seq_write()</tt>. Since there is already a lock protecting all of these accesses, adding atomic bit operations is just overhead unless there is a reason to do so.</p> <p>Please provide more details about the original bug so there is justification for the patch to be landed.</p> <p>Andreas, there was an old crash with "ASSERTION( lov-&gt;lov_qos.lq_statfs_in_progress )" failure:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>Oct 11 01:24:25 lus207n03 kernel: LustreError: 140684:0:(lov_qos.c:1136:qos_statfs_done()) ASSERTION( lov-&gt;lov_qos.lq_statfs_in_progress ) failed: Oct 11 01:24:25 lus207n03 kernel: LustreError: 140684:0:(lov_qos.c:1136:qos_statfs_done()) LBUG Oct 11 01:24:25 lus207n03 kernel: Pid: 140684, comm: ptlrpcd Oct 11 01:24:25 lus207n03 kernel: Oct 11 01:24:25 lus207n03 kernel: Call Trace: Oct 11 01:24:25 lus207n03 kernel: [&lt;ffffffffa042c825&gt;] libcfs_debug_dumpstack+0x55/0x80 [libcfs] Oct 11 01:24:25 lus207n03 kernel: [&lt;ffffffffa042ce27&gt;] lbug_with_loc+0x47/0xb0 [libcfs] Oct 11 01:24:25 lus207n03 kernel: [&lt;ffffffffa0a56829&gt;] qos_statfs_done+0x89/0x90 [lov] Oct 11 01:24:25 lus207n03 kernel: [&lt;ffffffffa0a4a166&gt;] cb_statfs_update+0x346/0x580 [lov] Oct 11 01:24:25 lus207n03 kernel: [&lt;ffffffffa09cdcb6&gt;] osc_statfs_interpret+0xd6/0x400 [osc] Oct 11 01:24:25 lus207n03 kernel: [&lt;ffffffffa073171b&gt;] ptlrpc_check_set+0x29b/0x1d50 [ptlrpc] Oct 11 01:24:25 lus207n03 kernel: [&lt;ffffffff814eaf6a&gt;] ? schedule_timeout+0x19a/0x2e0 Oct 11 01:24:25 lus207n03 kernel: [&lt;ffffffff8107c180&gt;] ? process_timeout+0x0/0x10 Oct 11 01:24:25 lus207n03 kernel: [&lt;ffffffffa07636b0&gt;] ptlrpcd_check+0x1a0/0x230 [ptlrpc] Oct 11 01:24:25 lus207n03 kernel: [&lt;ffffffffa0763a43&gt;] ptlrpcd+0x303/0x370 [ptlrpc] Oct 11 01:24:25 lus207n03 kernel: [&lt;ffffffff8105f9f0&gt;] ? default_wake_function+0x0/0x20 Oct 11 01:24:25 lus207n03 kernel: [&lt;ffffffffa0763740&gt;] ? ptlrpcd+0x0/0x370 [ptlrpc] Oct 11 01:24:25 lus207n03 kernel: [&lt;ffffffff81090806&gt;] kthread+0x96/0xa0 Oct 11 01:24:25 lus207n03 kernel: [&lt;ffffffff8100c14a&gt;] child_rip+0xa/0x20 Oct 11 01:24:25 lus207n03 kernel: [&lt;ffffffff81090770&gt;] ? kthread+0x0/0xa0 </pre> </div></div> <p>however the assertion doesn't exist in recent Lustre code. a wrong update of bitfield flags still possible due to an unprotected access through lod_qos_thresholdrr_seq_write() , though w/o a crash, just some updates to  lq_reset/lq_same_space can be lost.</p> <p>It would be good to include such explanation into the commit message of the patch, so that it is clear why it should land. </p> <p>Oleg Drokin (green@whamcloud.com) merged in patch <a href="https://review.whamcloud.com/18812/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/18812/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-7853" title="Fixes bitfield in lod qos code" class="issue-link" data-issue-key="LU-7853"><del>LU-7853</del></a> lod: fixes bitfield in lod qos code<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 3bae39f0a5b98a279fb5f7b8d00211ac0d09366f</p> <p>Landed for 2.15</p> Related LU-14277 Development Rank 1|hzy3rj: Rank (Obsolete) 9223372036854775807 Severity