)]}'
{
  "commit": "7ce9d5d1f3c8736511daa413c64985a05b2feee3",
  "tree": "89b30c50d6e09467f43f4f824d04838e9bb33026",
  "parents": [
    "fec6c6fec3e20637bee5d276fb61dd8b49a3f9cc"
  ],
  "author": {
    "name": "Eric Sandeen",
    "email": "sandeen@redhat.com",
    "time": "Wed Mar 04 18:38:18 2009 -0500"
  },
  "committer": {
    "name": "Theodore Ts\u0027o",
    "email": "tytso@mit.edu",
    "time": "Wed Mar 04 18:38:18 2009 -0500"
  },
  "message": "ext4: fix ext4_free_inode() vs. ext4_claim_inode() race\n\nI was seeing fsck errors on inode bitmaps after a 4 thread\ndbench run on a 4 cpu machine:\n\nInode bitmap differences: -50736 -(50752--50753) etc...\n\nI believe that this is because ext4_free_inode() uses atomic\nbitops, and although ext4_new_inode() *used* to also use atomic \nbitops for synchronization, commit \n393418676a7602e1d7d3f6e560159c65c8cbd50e changed this to use\nthe sb_bgl_lock, so that we could also synchronize against\nread_inode_bitmap and initialization of uninit inode tables.\n\nHowever, that change left ext4_free_inode using atomic bitops,\nwhich I think leaves no synchronization between setting \u0026 \nunsetting bits in the inode table.\n\nThe below patch fixes it for me, although I wonder if we\u0027re \ngetting at all heavy-handed with this spinlock...\n\nSigned-off-by: Eric Sandeen \u003csandeen@redhat.com\u003e\nReviewed-by: Aneesh Kumar K.V \u003caneesh.kumar@linux.vnet.ibm.com\u003e\nSigned-off-by: \"Theodore Ts\u0027o\" \u003ctytso@mit.edu\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "f18a919be70becf286c74364345a464e4d6e75e6",
      "old_mode": 33188,
      "old_path": "fs/ext4/ialloc.c",
      "new_id": "627f8c3337a3a24314624683ceac71ed30c72e95",
      "new_mode": 33188,
      "new_path": "fs/ext4/ialloc.c"
    }
  ]
}