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-8249 Lustre <p>While testing a patch I was able to deadlock all the CPU of my machine.<br/> After investigating the log reports I found out that in "LNetMDAttach" (implemented in lnet/lnet/lib-md.c) there is a call to the "vfree" function in interrupt context which is illegal in linux kernel versions prior to 3.10.</p> <p>I cannot be sure whether or not this was actually the cause of my problem though, because I have not been able to reproduce since then.</p> LU-8249

Potential deadlock in lnet

Bug Minor Resolved Fixed Doug Oucharek CEA patch Tue, 7 Jun 2016 23:11:49 +0000 Wed, 5 Aug 2020 13:50:23 +0000 Mon, 29 Aug 2016 13:04:09 +0000 Lustre 2.9.0 0 7 <p>Quentin Bouget (quentin.bouget.ocre@cea.fr) uploaded a new patch: <a href="http://review.whamcloud.com/20676" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/20676</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-8249" title="Potential deadlock in lnet" class="issue-link" data-issue-key="LU-8249"><del>LU-8249</del></a> lnet: potential deadlock in lnet<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: ef1052386265b73c129c2dc5d20bd86e175a8c0d</p> <p>Hello Quentin, could you provide additional infos to help us to understand the problem ?? Like the log reports you refer too, and may be a crash-dump is available too ??</p> <p>Hi Doug,</p> <p>Can you please investigate this patch?</p> <p>Thanks.<br/> Joe</p> <p>Hello Bruno, I actually do not have much, I did not realize what this was at the time. I thought it was related to my patch and would be easy to reproduce. The best I have is a partial calling stack incriminating "cfs_percpt_lock" (attachment file). I reviewed the code that used it and found the inverted "vfree" and "cfs_percpt_unlock" in "LNetMDAttach".</p> <p>Hello Quentin, even if I don't think it will fix the specific dead-lock situation you have encountered, I am not against your patch that sounds ok to comply to the rule against calling vfree() with a spin-lock currently granted, but then I think you should at least modify LNetMDBind() the same way and there also not to try to lnet_res_unlock() upon lnet_res_lock_current() failure.</p> <p>Also, you may have triggered an issue similar to the one tracked in <a href="https://jira.whamcloud.com/browse/LU-8334" title="OSS lockup" class="issue-link" data-issue-key="LU-8334"><del>LU-8334</del></a>, in fact we will need a crash-dump taken upon next occurrence to be able to determine the real root cause.</p> <p>What do you think?</p> <p>Indeed I missed the one in LnetMDBind().<br/> I'm not sure lnet_res_lock_current() can actually fail though, the return code that is tested after it is set by lnet_md_build() and I don't think there is any actual reason to take the spinlock upon failure (if it is to release it right after that).</p> <p>If this ever occurs again I will make sure to get a crash-dump.</p> <p>(New patch is available)</p> <p>Sorry, I meant for failures before lnet_res_lock_current(), but I see that this what you also implemented in the new patch-set #4 !</p> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="http://review.whamcloud.com/20676/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/20676/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-8249" title="Potential deadlock in lnet" class="issue-link" data-issue-key="LU-8249"><del>LU-8249</del></a> lnet: potential deadlock in lnet<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: cc025e667464672edd25da819e106854c220e668</p> <p>Landed for 2.9</p> Development Rank 1|hzydz3: Rank (Obsolete) 9223372036854775807 Severity