https://tracker.ceph.com/https://tracker.ceph.com/favicon.ico2011-12-12T03:19:30ZCeph Linux kernel client - Bug #1795: break d_lock > s_cap_lock orderinghttps://tracker.ceph.com/issues/1795?journal_id=75792011-12-12T03:19:30ZAmon Ott
<ul></ul><p>Seems fixed here now with git branch wip-d-lock.</p> Linux kernel client - Bug #1795: break d_lock > s_cap_lock orderinghttps://tracker.ceph.com/issues/1795?journal_id=77672012-01-03T10:48:49ZSage Weilsage@newdream.net
<ul><li><strong>Target version</strong> deleted (<del><i>v3.2</i></del>)</li></ul> Linux kernel client - Bug #1795: break d_lock > s_cap_lock orderinghttps://tracker.ceph.com/issues/1795?journal_id=77972012-01-03T10:52:12ZSage Weilsage@newdream.net
<ul><li><strong>translation missing: en.field_position</strong> set to <i>1</i></li></ul> Linux kernel client - Bug #1795: break d_lock > s_cap_lock orderinghttps://tracker.ceph.com/issues/1795?journal_id=78132012-01-03T11:14:21ZSage Weilsage@newdream.net
<ul><li><strong>Target version</strong> set to <i>v3.3</i></li><li><strong>translation missing: en.field_position</strong> deleted (<del><i>3</i></del>)</li><li><strong>translation missing: en.field_position</strong> set to <i>1</i></li><li><strong>translation missing: en.field_position</strong> changed from <i>1</i> to <i>699</i></li></ul> Linux kernel client - Bug #1795: break d_lock > s_cap_lock orderinghttps://tracker.ceph.com/issues/1795?journal_id=81402012-01-12T16:25:08ZAlex Elderelder@ieee.org
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li></ul><p>Discussed this with Sage. The problem arose because dentry_lease_is_valid()<br />is using the MDS session's s_cap_lock for protecting the atomic update of<br />s_cap_gen and s_cap_ttl. But it must do so while holding the dentry lock,<br />and that violates the lock ordering: s_cap_lock -> i_lock -> d_lock</p>
<p>Will introduce a new inner lock, d_lock -> s_gen_lock, which will be used<br />to protect only atomic updates of s_cap_gen and s_cap_ttl.</p> Linux kernel client - Bug #1795: break d_lock > s_cap_lock orderinghttps://tracker.ceph.com/issues/1795?journal_id=81572012-01-13T11:54:26ZAlex Elderelder@ieee.org
<ul></ul><p>I have posted a series of four proposed patches to the list to address<br />this, along with a few other issues identified while looking at this.</p>
<p>The first one introduces a new spinlock, s_gen_ttl_lock, which is used<br />instead of s_cap_lock to ensure the two fields are updated or sampled<br />atomically where this is needed.</p>
<p>The second replaces the use of the special value 0 for the ttl field<br />to indicate "some time in the past," instead using (jiffies - 1).</p>
<p>The last two change the types for these two fields to atomic types<br />to guarantee operations on each is atomic.</p>
<p>Will commit to master once they're reviewed.</p> Linux kernel client - Bug #1795: break d_lock > s_cap_lock orderinghttps://tracker.ceph.com/issues/1795?journal_id=81592012-01-13T14:28:17ZAlex Elderelder@ieee.org
<ul></ul><p>OK, after several iterations and some discussion we<br />concluded the last two patches (turning these things<br />into atomics) were not actually needed.</p> Linux kernel client - Bug #1795: break d_lock > s_cap_lock orderinghttps://tracker.ceph.com/issues/1795?journal_id=81602012-01-13T15:53:01ZSage Weilsage@newdream.net
<ul><li><strong>Assignee</strong> set to <i>Alex Elder</i></li></ul> Linux kernel client - Bug #1795: break d_lock > s_cap_lock orderinghttps://tracker.ceph.com/issues/1795?journal_id=81642012-01-13T19:14:49ZAlex Elderelder@ieee.org
<ul></ul><p>I was hitting some odd behavior while testing. Will try again over<br />the weekend or early next week.</p>
<p>Also, a note: Sage said this warning can be triggered by causing<br />an MDS restart. Lockdep doesn't work for UML builds so it has to<br />be done in a "real" kernel. It's possible to script this in<br />teuthology, but maybe not obvious.</p> Linux kernel client - Bug #1795: break d_lock > s_cap_lock orderinghttps://tracker.ceph.com/issues/1795?journal_id=81872012-01-18T05:57:20ZAlex Elderelder@ieee.org
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Resolved</i></li></ul><p>I have verified under UML that no new problems arise with the<br />fix in place. I have not verified the lockdep warnings are<br />addressed, but I have pretty good confidence this has been<br />addressed. The fix is committed to master.</p>
<p>Marking this resolved.</p>