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-8656 Lustre <p>In vvp_io_write_start, we check "IS_NOSEC" to see whether or not to take the inode mutex. (This is to protect the automatic setuid bit removal when writing to a file.)</p> <p>This was added in patch <a href="http://review.whamcloud.com/19840" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/19840</a> "<a href="https://jira.whamcloud.com/browse/LU-8025" title="ll_direct_io code introduced in LU-6260 is based on 2.4/2.5, ignores LU-1669" class="issue-link" data-issue-key="LU-8025"><del>LU-8025</del></a> llite: make vvp_io_write_start lockless for newer kernels". </p> <p>Unfortunately, it looks like that check is not working correctly, and is always returning false, causing us to take the inode mutex. This may have some dependence on kernel version, as different versions vary in whether they provide IS_NOSEC.</p> LU-8656

IS_NOSEC check in vvp_io_write_start always returns false

Bug Minor Resolved Fixed Patrick Farrell Patrick Farrell Fri, 30 Sep 2016 18:25:39 +0000 Tue, 8 Jun 2021 17:55:04 +0000 Sat, 10 Jun 2017 12:44:37 +0000 Lustre 2.10.0 0 5 <p>Patrick Farrell (paf@cray.com) uploaded a new patch: <a href="http://review.whamcloud.com/22853" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/22853</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-8656" title="IS_NOSEC check in vvp_io_write_start always returns false" class="issue-link" data-issue-key="LU-8656"><del>LU-8656</del></a> test: test IS_NOSEC and i_mutex usage<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 21f2167063086ae7651722991cb2a1fd49467ad0</p> <p>Which kernel versions is this broken on? The backwards macros are taken straight from the upstream kernel.</p> <p>Confirmed the IS_NOSEC check isn't working right on CentOS 6 (which does not provide its own version of the check) and on SLES 12, which does.</p> <p>Andreas and I discussed this at LAD, I will share details of what we figured out as I work on fixing this.</p> <p>James,</p> <p>I don't know exactly. That's part of why I contributed the test, so it can run on the Intel infrastructure and hopefully on a few different kernel versions.</p> <p>James,</p> <p>Can you point me at where in the upstream kernel? I see this:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"><span class="code-keyword">static</span> inline void inode_has_no_xattr(struct inode *inode) { <span class="code-keyword">if</span> (!is_sxid(inode-&gt;i_mode) &amp;&amp; (inode-&gt;i_sb-&gt;s_flags &amp; MS_NOSEC)) inode-&gt;i_flags |= S_NOSEC; } </pre> </div></div> <p>But the second part of that is important too, perhaps?</p> <p>One weird note - I don't see why the check is wrong on CentOS 6, where IS_NOSEC is not provided by the kernel. In that case, it looks like our test should work. But it doesn't seem to, at least if my test framework test is correct. (I ran it outside of the framework, but still.)</p> <p>The commit that introduced the IS_NOSEC work is 69b4573296469fd3f70cf7044693074980517067 for the linux kernel.</p> <p>Patrick or James, it would be useful if you could provide a stack trace of where/how <tt>file_remove_perms()</tt> gets called, because I just can't find it in the code.</p> <p>Andreas -</p> <p>File_remove_privs.</p> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="https://review.whamcloud.com/22853/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/22853/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-8656" title="IS_NOSEC check in vvp_io_write_start always returns false" class="issue-link" data-issue-key="LU-8656"><del>LU-8656</del></a> vvp: Add S_NOSEC support<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 8bc4b26453fb9d3296475ab3b9c9f3a9bf905afc</p> <p>Landed for 2.10</p> Related LU-8025 LU-8162 Development Rank 1|hzyq4v: Rank (Obsolete) 9223372036854775807 Severity