)]}'
{
  "commit": "7ef55b8a05c02db7c07d81827c69fe8f124e8654",
  "tree": "f588e5256e88595d04662c1faf105f9b95656c6b",
  "parents": [
    "77d6e1397a004c9376fed855e4164ca2b1dba2ed"
  ],
  "author": {
    "name": "Srinivasa Ds",
    "email": "srinivasa@in.ibm.com",
    "time": "Thu Nov 02 22:07:12 2006 -0800"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@g5.osdl.org",
    "time": "Fri Nov 03 12:27:57 2006 -0800"
  },
  "message": "[PATCH] NFS4: fix for recursive locking problem\n\nWhen I was performing some operations on NFS, I got below error on server\nside.\n\n  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n  [ INFO: possible recursive locking detected ]\n  2.6.19-prep #1\n  ---------------------------------------------\n  nfsd4/3525 is trying to acquire lock:\n   (\u0026inode-\u003ei_mutex){--..}, at: [\u003cc0611e5a\u003e] mutex_lock+0x21/0x24\n\n  but task is already holding lock:\n   (\u0026inode-\u003ei_mutex){--..}, at: [\u003cc0611e5a\u003e] mutex_lock+0x21/0x24\n\n  other info that might help us debug this:\n  2 locks held by nfsd4/3525:\n   #0:  (client_mutex){--..}, at: [\u003cc0611e5a\u003e] mutex_lock+0x21/0x24\n   #1:  (\u0026inode-\u003ei_mutex){--..}, at: [\u003cc0611e5a\u003e] mutex_lock+0x21/0x24\n\n  stack backtrace:\n   [\u003cc04051ed\u003e] show_trace_log_lvl+0x58/0x16a\n   [\u003cc04057fa\u003e] show_trace+0xd/0x10\n   [\u003cc0405913\u003e] dump_stack+0x19/0x1b\n   [\u003cc043b6f1\u003e] __lock_acquire+0x778/0x99c\n   [\u003cc043be86\u003e] lock_acquire+0x4b/0x6d\n   [\u003cc0611ceb\u003e] __mutex_lock_slowpath+0xbc/0x20a\n   [\u003cc0611e5a\u003e] mutex_lock+0x21/0x24\n   [\u003cc047fd7e\u003e] vfs_rmdir+0x76/0xf8\n   [\u003cf94b7ce9\u003e] nfsd4_clear_clid_dir+0x2c/0x41 [nfsd]\n   [\u003cf94b7de9\u003e] nfsd4_remove_clid_dir+0xb1/0xe8 [nfsd]\n   [\u003cf94b307b\u003e] laundromat_main+0x9b/0x1c3 [nfsd]\n   [\u003cc04333d6\u003e] run_workqueue+0x7a/0xbb\n   [\u003cc0433d0b\u003e] worker_thread+0xd2/0x107\n   [\u003cc0436285\u003e] kthread+0xc3/0xf2\n   [\u003cc0402005\u003e] kernel_thread_helper+0x5/0xb\n  \u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nCause for this problem was,2 successive mutex_lock calls on 2 diffrent inodes ,as shown below\n\n\tstatic int\n\tnfsd4_clear_clid_dir(struct dentry *dir, struct dentry *dentry)\n\t{\n\t        int status;\n\n\t        /* For now this directory should already be empty, but we empty it of\n        \t * any regular files anyway, just in case the directory was created by\n\t         * a kernel from the future.... */\n        \tnfsd4_list_rec_dir(dentry, nfsd4_remove_clid_file);\n\t        mutex_lock(\u0026dir-\u003ed_inode-\u003ei_mutex);\n\t        status \u003d vfs_rmdir(dir-\u003ed_inode, dentry);\n\t...\n\n\tint vfs_rmdir(struct inode *dir, struct dentry *dentry)\n\t{\n\t        int error \u003d may_delete(dir, dentry, 1);\n\n\t        if (error)\n\t                return error;\n\n\t        if (!dir-\u003ei_op || !dir-\u003ei_op-\u003ermdir)\n        \t        return -EPERM;\n\n\t        DQUOT_INIT(dir);\n\n\t        mutex_lock(\u0026dentry-\u003ed_inode-\u003ei_mutex);\n\t...\n\nSo I have developed the patch to overcome this problem.\n\nSigned-off-by: Srinivasa DS \u003csrinivasa@in.ibm.com\u003e\nCc: Neil Brown \u003cneilb@suse.de\u003e\nCc: Peter Zijlstra \u003ca.p.zijlstra@chello.nl\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "e9d07704680e7f5e99adad09c643f24e16442ee1",
      "old_mode": 33188,
      "old_path": "fs/nfsd/nfs4recover.c",
      "new_id": "81b8565d3837a58137c1c589905e294f0bbb2ccd",
      "new_mode": 33188,
      "new_path": "fs/nfsd/nfs4recover.c"
    }
  ]
}