<!-- 
RSS generated by JIRA (9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c) at Sat Feb 10 02:53:42 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-12564] ptlrpcd daemon sleeps while holding imp_lock spinlock</title>
                <link>https://jira.whamcloud.com/browse/LU-12564</link>
                <project id="10000" key="LU">Lustre</project>
                    <description>&lt;p&gt;RCU stalls occurring in ptlrpc_check_set were tracked to a ptlrpcd daemon that was sleeping while holding an import lock spinlock.&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;PID: 12920  TASK: ffff880834b47040  CPU: 7   COMMAND: &quot;ptlrpcd_03_02&quot;
 #0 [ffffc90005d5bb20] __schedule at ffffffff816a067c
 #1 [ffffc90005d5bba8] __cond_resched_lock at ffffffff810855ea
 #2 [ffffc90005d5bbc0] __purge_vmap_area_lazy at ffffffff811a2210
 #3 [ffffc90005d5bbf0] free_vmap_area_noflush at ffffffff811a22bd
 #4 [ffffc90005d5bc08] remove_vm_area at ffffffff811a4477
 #5 [ffffc90005d5bc28] __vunmap at ffffffff811a44b6
 #6 [ffffc90005d5bc50] vfree at ffffffff811a459e
 #7 [ffffc90005d5bc68] null_free_repbuf at ffffffffa08190d8 [ptlrpc]
 #8 [ffffc90005d5bc80] sptlrpc_cli_free_repbuf at ffffffffa080b3d0 [ptlrpc]
 #9 [ffffc90005d5bca0] __ptlrpc_req_finished at ffffffffa07cfb35 [ptlrpc]
#10 [ffffc90005d5bcd0] ptlrpc_free_request at ffffffffa07d03ca [ptlrpc]
#11 [ffffc90005d5bce8] ptlrpc_free_committed at ffffffffa07d2bca [ptlrpc]
#12 [ffffc90005d5bd30] ptlrpc_check_set at ffffffffa07d5eb1 [ptlrpc]
#13 [ffffc90005d5bdd0] ptlrpcd_check at ffffffffa08022dc [ptlrpc]
#14 [ffffc90005d5be18] ptlrpcd at ffffffffa080284e [ptlrpc]
#15 [ffffc90005d5bf08] kthread at ffffffff8107c167
#16 [ffffc90005d5bf50] ret_from_fork at ffffffff8180024a
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;Examining the code in ptlrpc_check_set()-&amp;gt;after_reply() shows that ptlrpc_free_committed is called while holding the imp_lock.&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;1408 static int after_reply(struct ptlrpc_request *req)
1409 {
1410         struct obd_import *imp = req-&amp;gt;rq_import;
.....
1551         if (imp-&amp;gt;imp_replayable) {
1552                 spin_lock(&amp;amp;imp-&amp;gt;imp_lock);
1553                 /*
1554                  * No point in adding already-committed requests to the replay
1555                  * list, we will just remove them immediately. b=9829
1556                  */
1557                 if (req-&amp;gt;rq_transno != 0 &amp;amp;&amp;amp;
1558                     (req-&amp;gt;rq_transno &amp;gt;
1559                      lustre_msg_get_last_committed(req-&amp;gt;rq_repmsg) ||
1560                      req-&amp;gt;rq_replay)) {
1561                         /** version recovery */
1562                         ptlrpc_save_versions(req);
1563                         ptlrpc_retain_replayable_request(req, imp);
1564                 } else if (req-&amp;gt;rq_commit_cb &amp;amp;&amp;amp;
1565                            list_empty(&amp;amp;req-&amp;gt;rq_replay_list)) {
1566                         /*
1567                          * NB: don&apos;t call rq_commit_cb if it&apos;s already on
1568                          * rq_replay_list, ptlrpc_free_committed() will call
1569                          * it later, see LU-3618 for details
1570                          */
1571                         spin_unlock(&amp;amp;imp-&amp;gt;imp_lock);
1572                         req-&amp;gt;rq_commit_cb(req);
1573                         spin_lock(&amp;amp;imp-&amp;gt;imp_lock);
1574                 }
1575
1576                 /*
1577                  * Replay-enabled imports return commit-status information.
1578                  */
1579                 committed = lustre_msg_get_last_committed(req-&amp;gt;rq_repmsg);
1580                 if (likely(committed &amp;gt; imp-&amp;gt;imp_peer_committed_transno))
1581                         imp-&amp;gt;imp_peer_committed_transno = committed;
1582
1583                 ptlrpc_free_committed(imp);
.....
1599                 spin_unlock(&amp;amp;imp-&amp;gt;imp_lock);
1600         }
1601
1602         RETURN(rc);
1603 }
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;p&gt;This causes a deadlock when another ptlrpcd daemon spins on a CPU trying to get the lock and the holder of the lock gets scheduled on the same CPU.&lt;/p&gt;
&lt;div class=&quot;preformatted panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;preformattedContent panelContent&quot;&gt;
&lt;pre&gt;crash_x86_64&amp;gt; bt -t 12918
PID: 12918  TASK: ffff880825b3a1c0  CPU: 7   COMMAND: &quot;ptlrpcd_03_00&quot;
              START: __schedule at ffffffff816a067c
  [ffffc9000536bd10] lustre_msg_set_transno at ffffffffa07e1df7 [ptlrpc]
  [ffffc9000536bd20] _raw_spin_lock at ffffffff816a5951     &amp;lt;--- waiting on imp_lock
  [ffffc9000536bd30] ptlrpc_check_set at ffffffffa07d5e3e [ptlrpc]
  [ffffc9000536bd88] schedule_timeout at ffffffff816a4459
  [ffffc9000536bdd0] ptlrpcd_check at ffffffffa08022dc [ptlrpc]
  [ffffc9000536be18] ptlrpcd at ffffffffa080284e [ptlrpc]
  [ffffc9000536be58] default_wake_function at ffffffff81086380
  [ffffc9000536bf08] kthread at ffffffff8107c167
  [ffffc9000536bf18] ptlrpcd at ffffffffa08024d0 [ptlrpc]
  [ffffc9000536bf20] kthread at ffffffff8107c040
  [ffffc9000536bf50] ret_from_fork at ffffffff8180024a

crash_x86_64&amp;gt; bt -l 12918 | grep -A 1 ptlrpc_check_set
 #2 [ffffc9000536bd30] ptlrpc_check_set at ffffffffa07d5e3e [ptlrpc]
    /home/abuild/rpmbuild/BUILD/cray-lustre-2.11.0.200_cray_90_g022bd19/lustre/ptlrpc/client.c: 1474

ptlrpcd_03_00 is trying to get the imp_lock; ptlrpd_03_02 holds it:

CPU 7 RUNQUEUE: ffff88085f9e1f00
  CURRENT: PID: 12918  TASK: ffff880825b3a1c0  COMMAND: &quot;ptlrpcd_03_00&quot;
  RT PRIO_ARRAY: ffff88085f9e2140
     [no tasks queued]
  CFS RB_ROOT: ffff88085f9e1fb0
     [120] PID: 3968   TASK: ffff88050760afc0  COMMAND: &quot;kworker/7:0&quot;
     [120] PID: 13361  TASK: ffff88083f701080  COMMAND: &quot;gunicorn&quot;
     [120] PID: 32734  TASK: ffff880333e06480  COMMAND: &quot;tail&quot;
     [120] PID: 13384  TASK: ffff880837144140  COMMAND: &quot;gunicorn&quot;
     [120] PID: 15161  TASK: ffff880825ea1240  COMMAND: &quot;sssd_nss&quot;
     [120] PID: 14128  TASK: ffff88076005a040  COMMAND: &quot;mongod&quot;
     [120] PID: 10737  TASK: ffff880836f86240  COMMAND: &quot;cron&quot;
     [120] PID: 44     TASK: ffff88082372b000  COMMAND: &quot;ksoftirqd/7&quot;
     [120] PID: 12920  TASK: ffff880834b47040  COMMAND: &quot;ptlrpcd_03_02&quot;
&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;</description>
                <environment></environment>
        <key id="56442">LU-12564</key>
            <summary>ptlrpcd daemon sleeps while holding imp_lock spinlock</summary>
                <type id="1" iconUrl="https://jira.whamcloud.com/secure/viewavatar?size=xsmall&amp;avatarId=11303&amp;avatarType=issuetype">Bug</type>
                                            <priority id="3" iconUrl="https://jira.whamcloud.com/images/icons/priorities/major.svg">Major</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="green">Oleg Drokin</assignee>
                                    <reporter username="amk">Ann Koehler</reporter>
                        <labels>
                    </labels>
                <created>Thu, 18 Jul 2019 16:40:43 +0000</created>
                <updated>Thu, 4 Mar 2021 16:56:19 +0000</updated>
                            <resolved>Thu, 3 Dec 2020 14:42:00 +0000</resolved>
                                    <version>Lustre 2.11.0</version>
                    <version>Lustre 2.10.8</version>
                                    <fixVersion>Lustre 2.14.0</fixVersion>
                    <fixVersion>Lustre 2.12.7</fixVersion>
                                        <due></due>
                            <votes>0</votes>
                                    <watches>7</watches>
                                                                            <comments>
                            <comment id="251648" author="amk" created="Thu, 18 Jul 2019 16:49:04 +0000"  >&lt;p&gt;An obvious solution is to convert the spinlock to a mutex. But is there a better solution? Any ideas/suggestions?&lt;/p&gt;</comment>
                            <comment id="251650" author="pfarrell" created="Thu, 18 Jul 2019 17:13:13 +0000"  >&lt;p&gt;Definitely don&apos;t want imp_lock to be a mutex, it&apos;s used too many places for too much in the RPC machinery.&#160; I&apos;m pretty sure sleeping would hurt performance pretty badly.&lt;/p&gt;

&lt;p&gt;It looks like a bit of a pain, but I think we have to move the freeing of the request outside of the imp_lock.&#160; (Once they&apos;re off the various lists, requests can&apos;t be found.)&lt;br/&gt;
Unless it&apos;s possible to convert these to use RCU or something, I think we need something like a &quot;ready to be freed&quot; list...?&lt;/p&gt;

&lt;p&gt;This looks like a slightly obnoxious reorganization, sorry.&lt;/p&gt;

&lt;p&gt;By the way, whatever patch this is, could it also remove:&lt;br/&gt;
ptlrpc_req_finished_with_imp_lock ?&lt;/p&gt;

&lt;p&gt;Which is unused and confusing...&lt;/p&gt;</comment>
                            <comment id="251651" author="pfarrell" created="Thu, 18 Jul 2019 17:19:10 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.whamcloud.com/secure/ViewProfile.jspa?name=amk&quot; class=&quot;user-hover&quot; rel=&quot;amk&quot;&gt;amk&lt;/a&gt;,&lt;/p&gt;

&lt;p&gt;Hmm.&#160; I&apos;m thinking RCU is the way to go, and maybe&#160;&lt;a href=&quot;https://jira.whamcloud.com/secure/ViewProfile.jspa?name=stancheff&quot; class=&quot;user-hover&quot; rel=&quot;stancheff&quot;&gt;stancheff&lt;/a&gt;&#160;can assist here.&lt;/p&gt;

&lt;p&gt;Looking at:&lt;br/&gt;
&lt;a href=&quot;https://review.whamcloud.com/#/c/35038/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://review.whamcloud.com/#/c/35038/&lt;/a&gt;&lt;/p&gt;

&lt;p&gt; I wonder if it&apos;s possible to just stick them on an RCU head (forget what I said about lists in the previous version of this - these things have their own rules you&apos;d have look in to) and then free them independently, via RCU callback.&lt;/p&gt;

&lt;p&gt;A few thoughts.&lt;br/&gt;
 1. If that route is taken, I think we&apos;d need to add an rcu_barrier in whatever code frees the import (there&apos;s at least one example in the Lustre code of this, though it&apos;s at module exit.&#160; Since we want the list protected by the import lock (I think ?), we&apos;d have to do it at import free time)&lt;br/&gt;
 2. I wonder if it&apos;s safe to sleep in an RCU callback.&#160; I suspect it is, but that&apos;s something we&apos;d need to double-check.&lt;/p&gt;</comment>
                            <comment id="251652" author="simmonsja" created="Thu, 18 Jul 2019 17:31:07 +0000"  >&lt;p&gt;Currently the udev event system internally takes spin locks which causes a sleep in context error. If you fix this then it resolves my uevent problems &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.whamcloud.com/images/icons/emoticons/smile.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&lt;/p&gt;</comment>
                            <comment id="251653" author="simmonsja" created="Thu, 18 Jul 2019 17:36:05 +0000"  >&lt;p&gt;Patrick is&#160;&lt;a href=&quot;https://jira.whamcloud.com/browse/LU-12362&quot; title=&quot;kernel warning &amp;#39;do not call blocking ops when !TASK_RUNNING &amp;#39; in ptlrpcd&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-12362&quot;&gt;&lt;del&gt;LU-12362&lt;/del&gt;&lt;/a&gt; also related to this?&lt;/p&gt;</comment>
                            <comment id="251665" author="pfarrell" created="Thu, 18 Jul 2019 20:53:51 +0000"  >&lt;p&gt;&lt;a href=&quot;https://jira.whamcloud.com/secure/ViewProfile.jspa?name=simmonsja&quot; class=&quot;user-hover&quot; rel=&quot;simmonsja&quot;&gt;simmonsja&lt;/a&gt;,&lt;/p&gt;

&lt;p&gt;No.&#160; It&apos;s similar, but unrelated.&#160; This one is sleeping while holding a spinlock (which is not strictly banned but is &lt;b&gt;really&lt;/b&gt;&#160;not a good idea, and we&apos;re seeing one aspect of the &apos;not a good idea&apos; part when another thread waits on the spinlock the whole time this thread is sleeping, which is both very wasteful and can easily cause a deadlock if all CPUs get busy with spinning threads).&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://jira.whamcloud.com/browse/LU-12362&quot; title=&quot;kernel warning &amp;#39;do not call blocking ops when !TASK_RUNNING &amp;#39; in ptlrpcd&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-12362&quot;&gt;&lt;del&gt;LU-12362&lt;/del&gt;&lt;/a&gt; on the other hand, is a different, weirder problem (but similar).&#160; The task is not in the running state because it&apos;s just checking the condition on a wait queue, so it&apos;s not considered to be running.&#160; Newer kernels complain about sleeping in this scenario, which seems reasonable.&#160; I don&apos;t know exactly what can go wrong in this case*, but you&apos;re supposed to do as little as possible when checking the condition for the wait queue.&#160; It&apos;s not a callback for doing work - It&apos;s a condition for sleeping.&#160; But we&apos;re using it as a callback for doing work.&lt;/p&gt;

&lt;p&gt;*Because it&apos;s allowed without warning in earlier kernels, I suspect it&apos;s &quot;nothing specific, but don&apos;t do it because it&apos;s bad and weird and the scheduler can&apos;t track you correctly&quot;. : )&lt;/p&gt;</comment>
                            <comment id="251666" author="pfarrell" created="Thu, 18 Jul 2019 20:55:06 +0000"  >&lt;p&gt;By the way, &lt;a href=&quot;https://jira.whamcloud.com/secure/ViewProfile.jspa?name=simmonsja&quot; class=&quot;user-hover&quot; rel=&quot;simmonsja&quot;&gt;simmonsja&lt;/a&gt;, I don&apos;t understand how this relates to your udev issue?&#160; Where&apos;s udev involved here?&#160; This is ptlrpc sleeping while freeing memory.&lt;/p&gt;</comment>
                            <comment id="251675" author="simmonsja" created="Thu, 18 Jul 2019 21:46:05 +0000"  >&lt;p&gt;[ 28.985694] BUG: sleeping function called from invalid context at mm/slab.c:3054&lt;br/&gt;
 [ 28.987603] in_atomic(): 1, irqs_disabled(): 0, pid: 3053, name: mount.lustre&lt;br/&gt;
 [ 28.988683] 1 lock held by mount.lustre/3053:&lt;br/&gt;
 [ 28.989707] #0: (&amp;amp;type-&amp;gt;s_umount_key#38/1){......}, at: &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff811f0bb8&amp;gt;&amp;#93;&lt;/span&gt; sget+0x258/0x470&lt;br/&gt;
 [ 28.992807] CPU: 1 PID: 3053 Comm: mount.lustre Tainted: G OE ------------ 3.10.0-debug #1&lt;br/&gt;
 [ 28.994066] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011&lt;br/&gt;
 [ 28.994744] ffff8800aef4c600 00000000873b1d09 ffff880099283910 ffffffff816fd400&lt;br/&gt;
 [ 28.996169] ffff880099283928 ffffffff810b0109 0000000000000000 ffff8800992839c0&lt;br/&gt;
 [ 28.997832] ffffffff811cd902 ffff8800992839d0 ffffffffa064bf21 ffffffffa064bf21&lt;br/&gt;
 [ 28.999740] Call Trace:&lt;br/&gt;
 [ 29.000459] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff816fd400&amp;gt;&amp;#93;&lt;/span&gt; dump_stack+0x19/0x1b&lt;br/&gt;
 [ 29.001075] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff810b0109&amp;gt;&amp;#93;&lt;/span&gt; __might_sleep+0xe9/0x110&lt;br/&gt;
 [ 29.001994] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff811cd902&amp;gt;&amp;#93;&lt;/span&gt; __kmalloc_track_caller+0x112/0x660&lt;br/&gt;
 [ 29.002756] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff813836a1&amp;gt;&amp;#93;&lt;/span&gt; ? vsnprintf+0x201/0x6a0&lt;br/&gt;
 [ 29.003751] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff8138779e&amp;gt;&amp;#93;&lt;/span&gt; ? kasprintf+0x4e/0x70&lt;br/&gt;
 [ 29.004815] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff81387711&amp;gt;&amp;#93;&lt;/span&gt; kvasprintf+0x61/0xa0&lt;br/&gt;
 [ 29.005820] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffff8138779e&amp;gt;&amp;#93;&lt;/span&gt; kasprintf+0x4e/0x70&lt;br/&gt;
 [ 29.006871] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa05b23b8&amp;gt;&amp;#93;&lt;/span&gt; import_set_state_nolock+0xa8/0x2f0 &lt;span class=&quot;error&quot;&gt;&amp;#91;ptlrpc&amp;#93;&lt;/span&gt;&lt;br/&gt;
 [ 29.007959] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa05b519d&amp;gt;&amp;#93;&lt;/span&gt; ptlrpc_connect_import+0x1dd/0x12a0 &lt;span class=&quot;error&quot;&gt;&amp;#91;ptlrpc&amp;#93;&lt;/span&gt;&lt;br/&gt;
 [ 29.009100] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa055782a&amp;gt;&amp;#93;&lt;/span&gt; client_connect_import+0x22a/0x470 &lt;span class=&quot;error&quot;&gt;&amp;#91;ptlrpc&amp;#93;&lt;/span&gt;&lt;br/&gt;
 [ 29.010193] &lt;span class=&quot;error&quot;&gt;&amp;#91;&amp;lt;ffffffffa03592ed&amp;gt;&amp;#93;&lt;/span&gt; lustre_start_mgc+0x1b9d/0x2560 &lt;span class=&quot;error&quot;&gt;&amp;#91;obdclass&amp;#93;&lt;/span&gt;&lt;/p&gt;

&lt;p&gt;So the import spin_lock has bitten me before. I could work around it but haven&apos;t sat down to think it out.&lt;/p&gt;

&lt;p&gt;Now is you move RCU then this becomes less of a problem.&lt;/p&gt;</comment>
                            <comment id="251676" author="pfarrell" created="Thu, 18 Jul 2019 22:25:29 +0000"  >&lt;p&gt;Ah, I see what you mean.&lt;/p&gt;

&lt;p&gt;Well, unfortunately, the plan here (at least my stab at one) doesn&apos;t involve changing the use of imp_spinlock - Just moving something out from under it in a clever way.&#160; I don&apos;t know what you could do about that alloc while printing thing...&#160; eek.&#160; I assume that&apos;s the CDEBUG rework.&lt;/p&gt;</comment>
                            <comment id="251708" author="stancheff" created="Fri, 19 Jul 2019 13:09:11 +0000"  >&lt;p&gt;Seems like a GFP_ATOMIC needs to be passed to kasprintf(), sometimes.&lt;/p&gt;

&lt;p&gt;This is a really hacky workaround variant of in_atomic():&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;

&lt;p&gt;&lt;tt&gt;static inline int _in_atomic_context(void)&lt;/tt&gt;&lt;br/&gt;
{{{}}&lt;br/&gt;
&lt;tt&gt;#ifdef PREEMPT_ACTIVE&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;#define PREEMPT_COUNT_MASK (~PREEMPT_ACTIVE)&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;#else&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;#define PREEMPT_COUNT_MASK (~0)&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;#endif&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;&#160; &#160; &#160; &#160; &#160;if (irqs_disabled() ||&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;&#160; &#160; &#160; &#160; &#160; &#160; &#160;is_idle_task(current) ||&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;&#160; &#160; &#160; &#160; &#160; &#160; &#160;(rcu_preempt_depth() + (preempt_count() &amp;amp; PREEMPT_COUNT_MASK)))&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;&#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160; &#160;return 1;&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;&#160; &#160; &#160; &#160; &#160;return 0;&lt;/tt&gt;&lt;br/&gt;
&lt;tt&gt;}&lt;/tt&gt;&lt;/p&gt;

&lt;p&gt;&lt;tt&gt;...&lt;/tt&gt;&lt;/p&gt;

&lt;p&gt;&lt;tt&gt;gfp_t gfp_mask = _in_atomic_context() ? GFP_ATOMIC : GFP_KERNEL;&lt;/tt&gt;&lt;/p&gt;

&lt;p&gt;&lt;tt&gt;envp&lt;span class=&quot;error&quot;&gt;&amp;#91;0&amp;#93;&lt;/span&gt; = kasprintf(gfp_mask, &quot;PARAM=%s.%.*s&quot;, param, (int) keylen, key);&lt;/tt&gt;&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;</comment>
                            <comment id="251712" author="pfarrell" created="Fri, 19 Jul 2019 14:00:07 +0000"  >&lt;p&gt;James,&lt;/p&gt;

&lt;p&gt;Do you have a ticket for the udev, etc, conversion, assuming that&apos;s the source of the kasprintf stuff?&#160; Shaun&apos;s suggestion looks very useful (thank you) and we should get it associated with that.&#160; (And also try to move the discussion of that issue there.)&lt;/p&gt;

&lt;p&gt;Shaun,&lt;/p&gt;

&lt;p&gt;Any comment on my RCU suggestion for the memory freeing issue (a little earlier in the LU, before James brought up the related kasprintf issue)?&lt;/p&gt;</comment>
                            <comment id="251715" author="stancheff" created="Fri, 19 Jul 2019 14:27:52 +0000"  >&lt;p&gt;I started looking through the code for the RCU option and I got a little lost &lt;img class=&quot;emoticon&quot; src=&quot;https://jira.whamcloud.com/images/icons/emoticons/smile.png&quot; height=&quot;16&quot; width=&quot;16&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/&gt;&#160;so I couldn&apos;t confirm that RCU is a good choice there ... a similar in_atomic() like scheme would also work .. pushing to a work queue if the kvfree could sleep.&lt;/p&gt;

&lt;p&gt;I &lt;b&gt;think&lt;/b&gt;&#160;an RCU-alike would also work here and sleeping in the call_rcu()/kfree_rcu() type of context should be okay.&lt;/p&gt;

&lt;p&gt;Another pattern I use is moving the free &apos;req&apos; entries to a local list_head and free them in bulk outside the spinlock.&lt;/p&gt;</comment>
                            <comment id="251718" author="pfarrell" created="Fri, 19 Jul 2019 16:29:18 +0000"  >&lt;p&gt;Ah, all right, thank you.&#160; I think maybe - &lt;a href=&quot;https://jira.whamcloud.com/secure/ViewProfile.jspa?name=amk&quot; class=&quot;user-hover&quot; rel=&quot;amk&quot;&gt;amk&lt;/a&gt; - that&apos;s the thing to try, and we can politely ask Neil Brown to look at it.&#160; (A work queue feels hacky, though obviously valid, so if we can avoid it... though again another reason for asking Neil is I imagine he knows what the normal pattern is in this sort of situation.)&lt;/p&gt;

&lt;p&gt;&quot;Another pattern I use is moving the free &apos;req&apos; entries to a local list_head and free them in bulk outside the spinlock.&quot;&lt;/p&gt;

&lt;p&gt;Yeah, I considered this as the first option.&#160; In this case, &quot;outside the spinlock&quot; can be several functions away, and there are various callers in to the chain who hold the spinlock for their own purposes, so it seemed impractical.&#160; (To add to the confusion, as you probably noticed, the relevant area is sometimes called &lt;b&gt;without&lt;/b&gt; the lock held.&#160; So that case would be straightforward to fix, since the freeing code only needs the spinlock relatively briefly...&#160; But it&apos;s also called by stuff that holds it over much larger swathes of code...)&lt;/p&gt;</comment>
                            <comment id="280916" author="gerrit" created="Tue, 29 Sep 2020 01:08:32 +0000"  >&lt;p&gt;&lt;del&gt;Oleg Drokin (green@whamcloud.com) uploaded a new patch:&lt;/del&gt; &lt;a href=&quot;https://review.whamcloud.com/40080&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://review.whamcloud.com/40080&lt;/a&gt;&lt;br/&gt;
&lt;del&gt;Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-12564&quot; title=&quot;ptlrpcd daemon sleeps while holding imp_lock spinlock&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-12564&quot;&gt;&lt;del&gt;LU-12564&lt;/del&gt;&lt;/a&gt; ptlrpc: Do not free requests under spinlock in ptlrpc_free_committed&lt;/del&gt;&lt;br/&gt;
&lt;del&gt;Project: fs/lustre-release&lt;/del&gt;&lt;br/&gt;
&lt;del&gt;Branch: b2_12&lt;/del&gt;&lt;br/&gt;
&lt;del&gt;Current Patch Set: 1&lt;/del&gt;&lt;br/&gt;
&lt;del&gt;Commit: 084e27911d36e6033bce616e30f8c8abcaa724d1&lt;/del&gt;&lt;/p&gt;</comment>
                            <comment id="281173" author="gerrit" created="Thu, 1 Oct 2020 06:29:38 +0000"  >&lt;p&gt;Oleg Drokin (green@whamcloud.com) uploaded a new patch: &lt;a href=&quot;https://review.whamcloud.com/40110&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://review.whamcloud.com/40110&lt;/a&gt;&lt;br/&gt;
Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-12564&quot; title=&quot;ptlrpcd daemon sleeps while holding imp_lock spinlock&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-12564&quot;&gt;&lt;del&gt;LU-12564&lt;/del&gt;&lt;/a&gt; Use vfree_atomic instead of vfree&lt;br/&gt;
Project: fs/lustre-release&lt;br/&gt;
Branch: b2_12&lt;br/&gt;
Current Patch Set: 1&lt;br/&gt;
Commit: 3fc8f4d0fdc3f37b3764681c2208f7a40c794922&lt;/p&gt;</comment>
                            <comment id="281177" author="adilger" created="Thu, 1 Oct 2020 08:22:39 +0000"  >&lt;p&gt;It seems that the sleepiness of &lt;tt&gt;vfree()&lt;/tt&gt; has been hit in other places, since &lt;tt&gt;vfree_atomic()&lt;/tt&gt; does exactly what Patrick suggested - putting the memory on a linked list and then freeing it in a work queue.&lt;/p&gt;</comment>
                            <comment id="281408" author="gerrit" created="Sun, 4 Oct 2020 03:52:23 +0000"  >&lt;p&gt;Oleg Drokin (green@whamcloud.com) uploaded a new patch: &lt;a href=&quot;https://review.whamcloud.com/40136&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://review.whamcloud.com/40136&lt;/a&gt;&lt;br/&gt;
Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-12564&quot; title=&quot;ptlrpcd daemon sleeps while holding imp_lock spinlock&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-12564&quot;&gt;&lt;del&gt;LU-12564&lt;/del&gt;&lt;/a&gt; libcfs: Use vfree_atomic instead of vfree&lt;br/&gt;
Project: fs/lustre-release&lt;br/&gt;
Branch: master&lt;br/&gt;
Current Patch Set: 1&lt;br/&gt;
Commit: e58c298d094cefe67a7d9625107188f2589afefe&lt;/p&gt;</comment>
                            <comment id="286569" author="gerrit" created="Thu, 3 Dec 2020 07:26:19 +0000"  >&lt;p&gt;Oleg Drokin (green@whamcloud.com) merged in patch &lt;a href=&quot;https://review.whamcloud.com/40136/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://review.whamcloud.com/40136/&lt;/a&gt;&lt;br/&gt;
Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-12564&quot; title=&quot;ptlrpcd daemon sleeps while holding imp_lock spinlock&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-12564&quot;&gt;&lt;del&gt;LU-12564&lt;/del&gt;&lt;/a&gt; libcfs: Use vfree_atomic instead of vfree&lt;br/&gt;
Project: fs/lustre-release&lt;br/&gt;
Branch: master&lt;br/&gt;
Current Patch Set: &lt;br/&gt;
Commit: 7a9c0ca690eb00a6e314322b62fb1fd3e9b31f0e&lt;/p&gt;</comment>
                            <comment id="286597" author="pjones" created="Thu, 3 Dec 2020 14:42:00 +0000"  >&lt;p&gt;Landed for 2.14&lt;/p&gt;</comment>
                            <comment id="293912" author="gerrit" created="Thu, 4 Mar 2021 08:35:52 +0000"  >&lt;p&gt;Oleg Drokin (green@whamcloud.com) merged in patch &lt;a href=&quot;https://review.whamcloud.com/40110/&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://review.whamcloud.com/40110/&lt;/a&gt;&lt;br/&gt;
Subject: &lt;a href=&quot;https://jira.whamcloud.com/browse/LU-12564&quot; title=&quot;ptlrpcd daemon sleeps while holding imp_lock spinlock&quot; class=&quot;issue-link&quot; data-issue-key=&quot;LU-12564&quot;&gt;&lt;del&gt;LU-12564&lt;/del&gt;&lt;/a&gt; libcfs: Use vfree_atomic instead of vfree&lt;br/&gt;
Project: fs/lustre-release&lt;br/&gt;
Branch: b2_12&lt;br/&gt;
Current Patch Set: &lt;br/&gt;
Commit: 1dc31de15ff270befceb64257bd84f15ffe75000&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10011">
                    <name>Related</name>
                                            <outwardlinks description="is related to ">
                                        <issuelink>
            <issuekey id="51084">LU-10756</issuekey>
        </issuelink>
                            </outwardlinks>
                                                                <inwardlinks description="is related to">
                                        <issuelink>
            <issuekey id="61176">LU-14024</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|i00jvj:</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>
                                                                                            <customfield id="customfield_10060" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>Severity</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10022"><![CDATA[3]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                        </customfields>
    </item>
</channel>
</rss>