<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 02:22:37 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-9026] Adapt to the removal of ib_get_dma_mr()</title>
                <link>https://jira.whamcloud.com/browse/LU-9026</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;&#160; &#160;As part of recent (last September) RDMA changes, the routine&#160;ib_get_dma_mr() was deleted and an extra &quot;flags&quot; parameter was added to ib_alloc_pd(). &#160;This was all done to stop upper layers from accessing the R-key for unregistered DMA memory regions. &#160;It seems that this opens the door to accessing any physical memory you want on a remote system thereby being a security issue.&lt;/p&gt;

&lt;p&gt;For the applicable changes, see these two kernel commits:&lt;/p&gt;

&lt;p&gt;&#160;&lt;br/&gt;
 &lt;font color=&quot;#064bba&quot;&gt;&lt;b&gt;from 4.9-rc1: change of arguments number for ib_alloc_pd&lt;/b&gt;&lt;/font&gt;&lt;br/&gt;
 commit ed082d36a7b2c27d1cda55fdfb28af18040c4a89&lt;br/&gt;
 Author: Christoph Hellwig &amp;lt;&lt;span class=&quot;nobr&quot;&gt;&lt;a href=&quot;mailto:hch@lst.de&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;&lt;font color=&quot;#0563c1&quot;&gt;&lt;ins&gt;hch@lst.de&lt;/ins&gt;&lt;/font&gt;&lt;sup&gt;&lt;img class=&quot;rendericon&quot; src=&quot;https://jira.whamcloud.com/images/icons/mail_small.gif&quot; height=&quot;12&quot; width=&quot;13&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/sup&gt;&lt;/a&gt;&lt;/span&gt;&amp;gt;&lt;br/&gt;
 Date:&#160;&#160; Mon Sep 5 12:56:17 2016 +0200&lt;br/&gt;
 &lt;font color=&quot;#064bba&quot;&gt;&lt;b&gt;from 4.9-rc1: removal of ib_get_dma_mr&lt;/b&gt;&lt;/font&gt;&lt;br/&gt;
 commit 5ef990f06bd7e3cf521b5705d898d8e43d04ea90&lt;br/&gt;
 Author: Christoph Hellwig &amp;lt;&lt;span class=&quot;nobr&quot;&gt;&lt;a href=&quot;mailto:hch@lst.de&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;&lt;font color=&quot;#0563c1&quot;&gt;&lt;ins&gt;hch@lst.de&lt;/ins&gt;&lt;/font&gt;&lt;sup&gt;&lt;img class=&quot;rendericon&quot; src=&quot;https://jira.whamcloud.com/images/icons/mail_small.gif&quot; height=&quot;12&quot; width=&quot;13&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/sup&gt;&lt;/a&gt;&lt;/span&gt;&amp;gt;&lt;br/&gt;
 Date:&#160;&#160; Mon Sep 5 12:56:21 2016 +0200&lt;br/&gt;
 &#160;&lt;/p&gt;

&lt;p&gt;LNet uses unregistered memory regions for short messages (lower latency). &#160;A &quot;method&quot; of still allowing us to work as we did before was added in the form of a PD variable called &quot;unsafe_global_rkey&quot; which is populated if you pass the flag &quot;IB_PD_UNSAFE_GLOBAL_RKEY&quot; as the new flags parameter to ib_alloc_pd(). &#160;As the name implies, this is considered unsafe and should not be done unless you are very confident in your security. &#160;Using it will trigger a warning to the kernel console.&lt;/p&gt;

&lt;p&gt;This change has caused a kernel maintainer to mark ko2iblnd as &quot;BROKEN&quot; in the 4.10 kernel build. &#160;To get rid of this broken tag, we need to fix this quickly so I am going to make use of the unsafe flag so I do not have to re-architect ko2iblnd for short messages. &#160;We need to test how much of a performance hit we get on short messages if we have to register all memory regions for better security. &#160;There is not enough time to do that now.&lt;/p&gt;

&lt;p&gt;So, this ticket was created to track the following changes to the staging version of LNet:&lt;/p&gt;
&lt;ol&gt;
	&lt;li&gt;Remove the BROKEN tag from lnet/Kconfig.&lt;/li&gt;
	&lt;li&gt;Pass the&#160;IB_PD_UNSAFE_GLOBAL_RKEY flag when calling ib_alloc_pd().&lt;/li&gt;
	&lt;li&gt;Everywhere we are using the device DMA mr to derive the R-key for non-registered memory regions, use the pd-&amp;gt;unsafe_global_rkey value instead (this will get rid of our call to&#160;ib_get_dma_mr()).&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;Once this is landed to staging, use this ticket to also make the change to community master with the necessary compile hooks to ensure the change is only done when it makes sense.&lt;/p&gt;</description>
                <environment></environment>
        <key id="43055">LU-9026</key>
            <summary>Adapt to the removal of ib_get_dma_mr()</summary>
                <type id="7" iconUrl="https://jira.whamcloud.com/images/icons/issuetypes/task_agile.png">Technical task</type>
                            <parent id="41865">LU-8874</parent>
                                    <priority id="1" iconUrl="https://jira.whamcloud.com/images/icons/priorities/blocker.svg">Blocker</priority>
                        <status id="5" iconUrl="https://jira.whamcloud.com/images/icons/statuses/resolved.png" description="A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.">Resolved</status>
                    <statusCategory id="3" key="done" colorName="success"/>
                                    <resolution id="1">Fixed</resolution>
                                        <assignee username="doug">Doug Oucharek</assignee>
                                    <reporter username="doug">Doug Oucharek</reporter>
                        <labels>
                            <label>lnet</label>
                    </labels>
                <created>Tue, 17 Jan 2017 23:02:35 +0000</created>
                <updated>Fri, 29 Sep 2017 19:28:18 +0000</updated>
                            <resolved>Thu, 23 Mar 2017 04:00:55 +0000</resolved>
                                    <version>Lustre 2.10.0</version>
                    <version>Upstream</version>
                                    <fixVersion>Lustre 2.10.0</fixVersion>
                    <fixVersion>Upstream</fixVersion>
                                        <due></due>
                            <votes>0</votes>
                                    <watches>20</watches>
                                                                            <comments>
                            <comment id="181088" author="gerrit" created="Wed, 18 Jan 2017 06:11:06 +0000"  >&lt;p&gt;Doug Oucharek (doug.s.oucharek@intel.com) uploaded a new patch: &lt;a href=&quot;https://review.whamcloud.com/24931&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://review.whamcloud.com/24931&lt;/a&gt;&lt;br/&gt;
Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-9026&quot; title=&quot;Adapt to the removal of ib_get_dma_mr()&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-9026&quot;&gt;&lt;del&gt;LU-9026&lt;/del&gt;&lt;/a&gt; lnet: Adapt to the removal of ib_get_dma_mr()&lt;br/&gt;
Project: fs/linux-staging&lt;br/&gt;
Branch: staging-testing&lt;br/&gt;
Current Patch Set: 1&lt;br/&gt;
Commit: 9a0076b26cd74a3bc2708163b93a04ddf3b54bdc&lt;/p&gt;</comment>
                            <comment id="181285" author="simmonsja" created="Thu, 19 Jan 2017 00:34:28 +0000"  >&lt;p&gt;I submitted a patch like this when it first broke and the response from Chris Hellwig was hell no. Mind you your patch is better than mine but he didn&apos;t want to reintroduce the security issues. Still this patch can be used as a base to get ko2iblnd working against upstream so we can work on the other important bits that need to be done&#160;&lt;/p&gt;</comment>
                            <comment id="181292" author="doug" created="Thu, 19 Jan 2017 01:04:02 +0000"  >&lt;p&gt;ko2iblnd was&#160;not secure before this patch, and the patch does not change that at all. &#160;If by changing the API to &quot;force&quot; us to be more secure, then Hellwig should not have put in the UNSAFE flag which I can see even he is using in the NFS code as well as the nvme guys. &#160;The issue I have with his solution is it &quot;can&quot; increase the latency of our small messages (even the nvme guys mention this in their code comments which is why they allow the use of the UNSAFE flag).&lt;/p&gt;

&lt;p&gt;I agree we need to eventually review this aspect to ko2iblnd security and improve it, but as a feature not as a quick bug fix. &#160;Given we are no worse off than we were before, I see no good argument against this fix.&lt;/p&gt;</comment>
                            <comment id="181293" author="simmonsja" created="Thu, 19 Jan 2017 01:08:46 +0000"  >&lt;p&gt;Just preparing you for Hellwig &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.whamcloud.com/images/icons/emoticons/wink.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&#160;&lt;/p&gt;</comment>
                            <comment id="181922" author="doug" created="Tue, 24 Jan 2017 15:20:30 +0000"  >&lt;p&gt;Naive question: if we switch to not using the global R-key on the upstream client, but the Lustre servers stay the way they are today (using the global R-key), will the upstream client be able to communicate with the server?&lt;/p&gt;

&lt;p&gt;If they can communicate, I&apos;m ok with changing this patch to not be using the global R-key and we will see what performance change we get.&lt;/p&gt;</comment>
                            <comment id="182026" author="doug" created="Tue, 24 Jan 2017 23:32:58 +0000"  >&lt;p&gt;It looks like we can have a new updated upstream client communicate with a older server.&lt;/p&gt;

&lt;p&gt;Based on my understanding of how ko2iblnd is using rkey&apos;s, to do this fix so we avoid the global rkey, we &quot;must&quot; use FMR/FastReg. &#160;That implies that map_on_demand cannot be zero (and the default has to be changed from the default).&lt;/p&gt;

&lt;p&gt;James: is this your understanding too? &#160;Are we ok with this change?&lt;/p&gt;</comment>
                            <comment id="182198" author="doug" created="Thu, 26 Jan 2017 00:31:32 +0000"  >&lt;p&gt;James: With the latest patch version, we have the upstream clients use a default map_on_demand of 32 and not allow them to be zero anymore. &#160;Autotest is trying to test them against servers based on master which have a default map_on_demand of zero. &#160;Those two settings are not compatible so all tests immediately fail.&lt;/p&gt;

&lt;p&gt;I cannot just change master to have a new default map_on_demand of 32 as that will break backwards compatibility between 2.10 and previous releases. &#160;Sigh. &#160;This change is going to be a political nightmare!&lt;/p&gt;

&lt;p&gt;How about this: I change master so that a node which has a map_on_demand of zero encounters another node with a non-zero map_on_demand, the current node changes to match the non-zero value? &#160;That should keep backward compatibility and prepare servers for working with the new upstream clients. &#160;We do have to be very clear that the upstream clients CANNOT work with servers older than 2.10 unless those servers have their map_on_demand values made non-zero. &#160;That sort of breaks our rule of a seamless backwards compatibility upgrade.&lt;/p&gt;

&lt;p&gt;Would this be an acceptable solution? &#160;Suggestions for a better way?&lt;/p&gt;</comment>
                            <comment id="182277" author="adilger" created="Thu, 26 Jan 2017 16:42:20 +0000"  >&lt;p&gt;Doug, I&apos;m not sure about the LNet/IB issues, but in terms of compatibility your proposal seems reasonable.  It would also be possible to backport the dynamic map_on_demand handling to our maintenance branches so that the older clients can mount newer servers in the future.&lt;/p&gt;</comment>
                            <comment id="183598" author="gerrit" created="Mon, 6 Feb 2017 18:50:08 +0000"  >&lt;p&gt;Doug Oucharek (doug.s.oucharek@intel.com) uploaded a new patch: &lt;a href=&quot;https://review.whamcloud.com/25277&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://review.whamcloud.com/25277&lt;/a&gt;&lt;br/&gt;
Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-9026&quot; title=&quot;Adapt to the removal of ib_get_dma_mr()&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-9026&quot;&gt;&lt;del&gt;LU-9026&lt;/del&gt;&lt;/a&gt; lnd: Adapt to the removal of ib_get_dma_mr()&lt;br/&gt;
Project: fs/lustre-release&lt;br/&gt;
Branch: master&lt;br/&gt;
Current Patch Set: 1&lt;br/&gt;
Commit: 54cc5d3d5e9a34c5d59b847bf0bcacccb7050755&lt;/p&gt;</comment>
                            <comment id="184872" author="simmonsja" created="Tue, 14 Feb 2017 23:11:33 +0000"  >&lt;p&gt;ORNL just hit this when someone attempted to build lustre with Mellanox 4.0 stack.&lt;/p&gt;</comment>
                            <comment id="184876" author="doug" created="Tue, 14 Feb 2017 23:21:48 +0000"  >&lt;p&gt;We need to get these two patches (one upstream, the other on master) landed soon then. &#160;Reviews?&lt;/p&gt;</comment>
                            <comment id="185670" author="simmonsja" created="Tue, 21 Feb 2017 17:33:21 +0000"  >&lt;p&gt;Upstream patch has been submitted. Waiting for it to land since no complaints. I tested the patch for master without the MOFED 4 stack. We now have MOFED 4 in our test system so I&apos;m going to give that a try next.&lt;/p&gt;</comment>
                            <comment id="186136" author="simmonsja" created="Fri, 24 Feb 2017 18:10:52 +0000"  >&lt;p&gt;Patch has landed upstream.&lt;/p&gt;</comment>
                            <comment id="186176" author="adilger" created="Sat, 25 Feb 2017 01:39:43 +0000"  >&lt;p&gt;Yay! Thanks Doug and James. Doug is also working on a couple more o2iblnd patches to avoid future similar breakage. Hopefully that will keep Christoph at bay for a while, and maybe even convince him that we want to get Lustre out of staging. &lt;/p&gt;

&lt;p&gt;Is there some linux-ib list that should be followed to get advance warning of such API changes in the future? It may be listed in the commit message for the original patches, or the get-maintainers script (or whatever it is called, or just the MAINTAINERS file) can be used to find the list. &lt;/p&gt;</comment>
                            <comment id="186745" author="shadow" created="Thu, 2 Mar 2017 07:12:05 +0000"  >&lt;p&gt;did any perf test run with it patch ?&lt;/p&gt;</comment>
                            <comment id="187034" author="doug" created="Fri, 3 Mar 2017 22:55:59 +0000"  >&lt;p&gt;I have been focused on doing some performance testing and am having some strange problems. &#160;This patch makes the default map_on_demand 256. &#160;With Lustre master, I am seeing a 5% reduction in performance with MLX QDR. &#160;Overall, not too bad given we are addressing a security hold with this change (i.e. we are being forced to do this).&lt;/p&gt;

&lt;p&gt;I downloaded the build from upstream with this change. &#160;Things are not good there. &#160;Ran into two bad problems:&lt;/p&gt;
&lt;ol&gt;
	&lt;li&gt;Performance is less than 1/2 from master.&lt;/li&gt;
	&lt;li&gt;Cannot use map_on_demand values less than 256 without getting this error message:&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;[ 1125.547100] LNetError: 22552:0:(o2iblnd_cb.c:1068:kiblnd_init_rdma()) RDMA is too large for peer 192.168.1.24@o2ib (131072), src size: 1048576 dst size: 1048576&lt;/p&gt;

&lt;p&gt;Some map_on_demand fixes/changes must be missing upstream. &#160;Whether that missing code is also causing the huge drop in performance, I don&apos;t yet know. &#160;I need to find an upstream build without this patch to see if performance has always been bad upstream and no one noticed.&lt;/p&gt;

&lt;p&gt;In any case, I will be opening a ticket to address number 2 as we need to find the missing code and get it upstream. &#160;Depending on how my additional testing for number 1 goes we will either be ok (and a 5% performance hit will accompany this change) or this patch has introduced a nasty problem which needs to be debugged before we can land it to master.&lt;/p&gt;</comment>
                            <comment id="187037" author="gerrit" created="Fri, 3 Mar 2017 23:11:57 +0000"  >&lt;p&gt;Doug Oucharek (doug.s.oucharek@intel.com) uploaded a new patch: &lt;a href=&quot;https://review.whamcloud.com/25802&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://review.whamcloud.com/25802&lt;/a&gt;&lt;br/&gt;
Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-9026&quot; title=&quot;Adapt to the removal of ib_get_dma_mr()&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-9026&quot;&gt;&lt;del&gt;LU-9026&lt;/del&gt;&lt;/a&gt; ko2iblnd: Test Patch to debug performance issue&lt;br/&gt;
Project: fs/linux-staging&lt;br/&gt;
Branch: staging-testing&lt;br/&gt;
Current Patch Set: 1&lt;br/&gt;
Commit: 171cd4eeda569fb5a19b6fde02240352adf7db24&lt;/p&gt;</comment>
                            <comment id="187061" author="doug" created="Sat, 4 Mar 2017 06:22:47 +0000"  >&lt;p&gt;Did some more testing and am starting to believe we have a general performance problem in the upstream LNet and is not caused by the patch in this ticket. &#160;I have opened two tickets corresponding to the two items above:&lt;/p&gt;
&lt;ol&gt;
	&lt;li&gt;Performance with IB/OPA: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-9179&quot; title=&quot;Upstream ko2iblnd has poor performance&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-9179&quot;&gt;&lt;del&gt;LU-9179&lt;/del&gt;&lt;/a&gt;&lt;/li&gt;
	&lt;li&gt;map_on_demand &amp;lt;256 a problem: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-9180&quot; title=&quot;Upstream ko2iblnd does not work with map_on_demand &amp;lt;256&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-9180&quot;&gt;&lt;del&gt;LU-9180&lt;/del&gt;&lt;/a&gt;&lt;/li&gt;
&lt;/ol&gt;


&lt;p&gt;I have not been able to validate the master version of this fix for performance issues yet because, well, I don&apos;t yet know how to build the master branch against Linux 4.9. &#160;Help appreciated.&lt;/p&gt;</comment>
                            <comment id="187243" author="dmiter" created="Mon, 6 Mar 2017 21:01:06 +0000"  >&lt;p&gt;Doug,&lt;br/&gt;
I&apos;m porting master to Linux 4.9 above your patch. I have one more patch to complete. You can look at series in top for now &lt;a href=&quot;https://review.whamcloud.com/25840&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://review.whamcloud.com/25840&lt;/a&gt;.&lt;/p&gt;</comment>
                            <comment id="187278" author="doug" created="Tue, 7 Mar 2017 02:05:33 +0000"  >&lt;p&gt;I just tried to build master against 4.9 (client only). &#160;It fails in the libcfs debug code. &#160;Will you be addressing that? &#160;I tried turning it off via a configure option, and that triggers a warning that you can&apos;t turn off debugging. &#160;Sigh.&lt;/p&gt;</comment>
                            <comment id="187291" author="shadow" created="Tue, 7 Mar 2017 04:50:45 +0000"  >&lt;p&gt;Dmitriy,&lt;/p&gt;

&lt;p&gt;your&apos;s patch isn&apos;t complete. Based on upstream commit, you need define an  &lt;br/&gt;
struct xattr_handlers to do same work. But you&apos;s patch just disable an xattr for lustre client. I don&apos;t think it good one.&lt;/p&gt;</comment>
                            <comment id="187551" author="simmonsja" created="Wed, 8 Mar 2017 22:43:21 +0000"  >&lt;p&gt;Dough you can test out the patch with MOFED 4. Its requires this patch to work. I have been running master +M MOFED 4 to test this patch. So far I haven&apos;t see the performance degradation you are seeing. Give MOFED 4 a try.&lt;/p&gt;</comment>
                            <comment id="187751" author="shadow" created="Fri, 10 Mar 2017 07:24:58 +0000"  >&lt;p&gt;James,&lt;/p&gt;

&lt;p&gt;did you test a mlx5 or mlx4 cards a specially QDR ?&lt;/p&gt;</comment>
                            <comment id="188140" author="simmonsja" created="Mon, 13 Mar 2017 19:05:36 +0000"  >&lt;p&gt;I tested mlx4 card (Connect-3) which is FDR. I need to try with the mlx5 driver once my Power8 node image is updated.&lt;/p&gt;</comment>
                            <comment id="188143" author="shadow" created="Mon, 13 Mar 2017 19:14:32 +0000"  >&lt;p&gt;mlx5 cards supports a fast memory registration mode, so should lack a performance problems,&lt;br/&gt;
but mlx4 + QDR cards (Connect-X2 possible) should have an issues with MD rpc traffic which need constantly send a reply with different kernel address, so memory mapping cache isn&apos;t work in this case.&lt;/p&gt;</comment>
                            <comment id="189354" author="gerrit" created="Thu, 23 Mar 2017 01:42:16 +0000"  >&lt;p&gt;Oleg Drokin (oleg.drokin@intel.com) merged in patch &lt;a href=&quot;https://review.whamcloud.com/25277/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://review.whamcloud.com/25277/&lt;/a&gt;&lt;br/&gt;
Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-9026&quot; title=&quot;Adapt to the removal of ib_get_dma_mr()&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-9026&quot;&gt;&lt;del&gt;LU-9026&lt;/del&gt;&lt;/a&gt; o2iblnd: Adapt to the removal of ib_get_dma_mr()&lt;br/&gt;
Project: fs/lustre-release&lt;br/&gt;
Branch: master&lt;br/&gt;
Current Patch Set: &lt;br/&gt;
Commit: e4297ef38561f1e788ba73ca0c8078a09dc8c303&lt;/p&gt;</comment>
                            <comment id="189371" author="pjones" created="Thu, 23 Mar 2017 04:00:55 +0000"  >&lt;p&gt;Landed to master which will now make testing easier.&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10120">
                    <name>Blocker</name>
                                            <outwardlinks description="is blocking">
                                                        </outwardlinks>
                                                                <inwardlinks description="is blocked by">
                                                        </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10010">
                    <name>Duplicate</name>
                                                                <inwardlinks description="is duplicated by">
                                        <issuelink>
            <issuekey id="48069">LU-9932</issuekey>
        </issuelink>
                            </inwardlinks>
                                    </issuelinktype>
                            <issuelinktype id="10011">
                    <name>Related</name>
                                            <outwardlinks description="is related to ">
                                        <issuelink>
            <issuekey id="28577">LU-6215</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="48300">LU-9983</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|hzz0xz:</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>