)]}'
{
  "commit": "7ef0d7377cb287e08f3ae94cebc919448e1f5dff",
  "tree": "3ab288db22eb17e76b5db1d9b8c6f7517570632f",
  "parents": [
    "f272b7bc447553410dde691aa31fc531adf9c175"
  ],
  "author": {
    "name": "Nick Piggin",
    "email": "npiggin@suse.de",
    "time": "Thu Mar 12 14:31:38 2009 -0700"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Thu Mar 12 16:20:24 2009 -0700"
  },
  "message": "fs: new inode i_state corruption fix\n\nThere was a report of a data corruption\nhttp://lkml.org/lkml/2008/11/14/121.  There is a script included to\nreproduce the problem.\n\nDuring testing, I encountered a number of strange things with ext3, so I\ntried ext2 to attempt to reduce complexity of the problem.  I found that\nfsstress would quickly hang in wait_on_inode, waiting for I_LOCK to be\ncleared, even though instrumentation showed that unlock_new_inode had\nalready been called for that inode.  This points to memory scribble, or\nsynchronisation problme.\n\ni_state of I_NEW inodes is not protected by inode_lock because other\nprocesses are not supposed to touch them until I_LOCK (and I_NEW) is\ncleared.  Adding WARN_ON(inode-\u003ei_state \u0026 I_NEW) to sites where we modify\ni_state revealed that generic_sync_sb_inodes is picking up new inodes from\nthe inode lists and passing them to __writeback_single_inode without\nwaiting for I_NEW.  Subsequently modifying i_state causes corruption.  In\nmy case it would look like this:\n\nCPU0                            CPU1\nunlock_new_inode()              __sync_single_inode()\n reg \u003c- inode-\u003ei_state\n reg -\u003e reg \u0026 ~(I_LOCK|I_NEW)   reg \u003c- inode-\u003ei_state\n reg -\u003e inode-\u003ei_state          reg -\u003e reg | I_SYNC\n                                reg -\u003e inode-\u003ei_state\n\nNon-atomic RMW on CPU1 overwrites CPU0 store and sets I_LOCK|I_NEW again.\n\nFix for this is rather than wait for I_NEW inodes, just skip over them:\ninodes concurrently being created are not subject to data integrity\noperations, and should not significantly contribute to dirty memory\neither.\n\nAfter this change, I\u0027m unable to reproduce any of the added warnings or\nhangs after ~1hour of running.  Previously, the new warnings would start\nimmediately and hang would happen in under 5 minutes.\n\nI\u0027m also testing on ext3 now, and so far no problems there either.  I\ndon\u0027t know whether this fixes the problem reported above, but it fixes a\nreal problem for me.\n\nCc: \"Jorge Boncompte [DTI2]\" \u003cjorge@dti2.net\u003e\nReported-by: Adrian Hunter \u003cext-adrian.hunter@nokia.com\u003e\nCc: Jan Kara \u003cjack@suse.cz\u003e\nCc: \u003cstable@kernel.org\u003e\nSigned-off-by: Nick Piggin \u003cnpiggin@suse.de\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "e5eaa62fd17f14e1d1b47c31966f4c1646eafde7",
      "old_mode": 33188,
      "old_path": "fs/fs-writeback.c",
      "new_id": "e3fe9918faafb710446f5bd73445eeca5ce5b0d7",
      "new_mode": 33188,
      "new_path": "fs/fs-writeback.c"
    },
    {
      "type": "modify",
      "old_id": "913ab2d9a5d10ecd183630c1a25770435613aca5",
      "old_mode": 33188,
      "old_path": "fs/inode.c",
      "new_id": "826fb0b9d1c38f4dbe4ad16c6ec938a7e31cdc88",
      "new_mode": 33188,
      "new_path": "fs/inode.c"
    }
  ]
}