<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 02:58:32 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>Whamcloud Community JIRA</title>
    <link>https://jira.whamcloud.com</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>9.4.14</version>
        <build-number>940014</build-number>
        <build-date>05-12-2023</build-date>
    </build-info>


<item>
            <title>[LU-13118] change client instance to respect ASLR</title>
                <link>https://jira.whamcloud.com/browse/LU-13118</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;The client mount currently uses the superblock address as the unique configuration instance (&quot;&lt;tt&gt;unsigned long cfg_instance&lt;/tt&gt;&quot; in the code) to distinguish multiple client mountpoints on the same node for the purpose of processing configuration records, which are treated as independent Lustre clients from the server point of view.&lt;/p&gt;

&lt;p&gt;This &lt;tt&gt;cfg_instance&lt;/tt&gt; can actually be any unique value as it is mostly just used as an identifier in messages and tunable parameters in procfs and sysfs.  One place where it is actually checked is &lt;tt&gt;config_log_find()&lt;/tt&gt;, but it only compares for identical instance numbers, and does not interpret the value itself.&lt;/p&gt;

&lt;p&gt;To comply with ASLR requirements, it would be better to use some other identifier for &lt;tt&gt;cfg_instance&lt;/tt&gt;.  It does not need to be unique across all clients, only within a single client.  One option would be a 64-bit random number, which has about a 1-in-4B chance of collision for multiple mounts on the same client, which is generally uncommon, but not impossible to hit.  Another option would be to use the client mount UUID, but this is a much larger value and changes would be needed to many parts of the code.  A compromise might be to use the 16-byte UUID folded over itself (i.e. first half XOR second half) to fit into an 8-byte value.&lt;/p&gt;

&lt;p&gt;On the server,  &lt;tt&gt;class_config_llog_handler()&lt;/tt&gt; and &lt;tt&gt;config_log_find_or_add()&lt;/tt&gt; use &lt;tt&gt;cfg_instance&lt;/tt&gt; to pass an obd device reference, but this is only used to get the &lt;tt&gt;obd_name&lt;/tt&gt; field.  We may be able to use &lt;tt&gt;config_log_find()&lt;/tt&gt; on the server to find the obd device back again?  We &lt;em&gt;might&lt;/em&gt; consider to just add the &lt;tt&gt;obd_name&lt;/tt&gt; string into the cfg_instance itself?  If we also added the client hostname into the cfg_instance this might be convenient to allow having tunable parameters that could be client specific (e.g. &quot;llite.*_node27.max_pages_per_rpc&quot;), but that might be overloading this too much.&lt;/p&gt;

&lt;p&gt;On the test front, the cfg_instance is used to distinguish client vs. server OSC devices, mostly using &quot;&lt;tt&gt;&amp;#42;&amp;#45;osc&amp;#45;[^M]&amp;#42;&lt;/tt&gt;&quot; or variants of this.  There are a few tests that are using &quot;&lt;tt&gt;&amp;#42;osc&amp;#45;&lt;span class=&quot;error&quot;&gt;&amp;#91;\-0\-9a\-f&amp;#93;&lt;/span&gt;&amp;#42;&lt;/tt&gt;&quot; but they should be made consistent.&lt;/p&gt;</description>
                <environment></environment>
        <key id="57754">LU-13118</key>
            <summary>change client instance to respect ASLR</summary>
                <type id="4" iconUrl="https://jira.whamcloud.com/secure/viewavatar?size=xsmall&amp;avatarId=11310&amp;avatarType=issuetype">Improvement</type>
                                            <priority id="4" iconUrl="https://jira.whamcloud.com/images/icons/priorities/minor.svg">Minor</priority>
                        <status id="1" iconUrl="https://jira.whamcloud.com/images/icons/statuses/open.png" description="The issue is open and ready for the assignee to start work on it.">Open</status>
                    <statusCategory id="2" key="new" colorName="default"/>
                                    <resolution id="-1">Unresolved</resolution>
                                        <assignee username="simmonsja">James A Simmons</assignee>
                                    <reporter username="adilger">Andreas Dilger</reporter>
                        <labels>
                    </labels>
                <created>Wed, 8 Jan 2020 21:40:50 +0000</created>
                <updated>Wed, 28 Sep 2022 08:15:28 +0000</updated>
                                                            <fixVersion>Upstream</fixVersion>
                                        <due></due>
                            <votes>0</votes>
                                    <watches>4</watches>
                                                                            <comments>
                            <comment id="261136" author="adilger" created="Mon, 13 Jan 2020 18:27:43 +0000"  >&lt;p&gt;Actually, a good option here would be to change this to use the ASLR remapping of the superblock address. That would be guaranteed unique, and also makes it easier to relate to other cases in the debug logs.  The reason that this was a problem originally is because the raw &quot;%p&quot; usage resulted in a string with leading spaces that screwed up parsing. If we can get the remapped address in the form of an integer that would work well. &lt;/p&gt;</comment>
                            <comment id="261138" author="adilger" created="Mon, 13 Jan 2020 18:45:25 +0000"  >&lt;p&gt;I now recall after reading &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-11809&quot; title=&quot;conf-sanity test 28A hangs on file system mount&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-11809&quot;&gt;&lt;del&gt;LU-11809&lt;/del&gt;&lt;/a&gt; that during early boot the kernel RNG isn&apos;t seeded enough to generate a random value for ASLR.  That makes me think that folding the 128-bit client mount UUID onto itself to make a 64-bit instance number is the best path forward.  Since the instance number has no other meaning and changes on every mount, we can always use something else in the future. &lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Related</name>
                                            <outwardlinks description="is related to ">
                                        <issuelink>
            <issuekey id="54334">LU-11803</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="54346">LU-11809</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="56278">LU-12511</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="59005">LU-13499</issuekey>
        </issuelink>
            <issuelink>
            <issuekey id="56292">LU-12521</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                    </issuelinks>
                <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                                                                                                                                            <customfield id="customfield_10890" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                        <customfield id="customfield_10390" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>1|i00rqf:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10090" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>9223372036854775807</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                </customfields>
    </item>
</channel>
</rss>