)]}'
{
  "commit": "05fe478dd04e02fa230c305ab9b5616669821dd3",
  "tree": "9b551aad196b66e5c773ed7619386a1bb5e14f41",
  "parents": [
    "00266770b8b3a6a77f896ca501a0613739086832"
  ],
  "author": {
    "name": "Nick Piggin",
    "email": "npiggin@suse.de",
    "time": "Tue Jan 06 14:39:08 2009 -0800"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Tue Jan 06 15:58:59 2009 -0800"
  },
  "message": "mm: write_cache_pages integrity fix\n\nIn write_cache_pages, nr_to_write is heeded even for data-integrity syncs,\nso the function will return success after writing out nr_to_write pages,\neven if that was not sufficient to guarantee data integrity.\n\nThe callers tend to set it to values that could break data interity\nsemantics easily in practice.  For example, nr_to_write can be set to\nmapping-\u003enr_pages * 2, however if a file has a single, dirty page, then\nfsync is called, subsequent pages might be concurrently added and dirtied,\nthen write_cache_pages might writeout two of these newly dirty pages,\nwhile not writing out the old page that should have been written out.\n\nFix this by ignoring nr_to_write if it is a data integrity sync.\n\nThis is a data integrity bug.\n\nThe reason this has been done in the past is to avoid stalling sync\noperations behind page dirtiers.\n\n \"If a file has one dirty page at offset 1000000000000000 then someone\n  does an fsync() and someone else gets in first and starts madly writing\n  pages at offset 0, we want to write that page at 1000000000000000.\n  Somehow.\"\n\nWhat we do today is return success after an arbitrary amount of pages are\nwritten, whether or not we have provided the data-integrity semantics that\nthe caller has asked for.  Even this doesn\u0027t actually fix all stall cases\ncompletely: in the above situation, if the file has a huge number of pages\nin pagecache (but not dirty), then mapping-\u003enrpages is going to be huge,\neven if pages are being dirtied.\n\nThis change does indeed make the possibility of long stalls lager, and\nthat\u0027s not a good thing, but lying about data integrity is even worse.  We\nhave to either perform the sync, or return -ELINUXISLAME so at least the\ncaller knows what has happened.\n\nThere are subsequent competing approaches in the works to solve the stall\nproblems properly, without compromising data integrity.\n\nSigned-off-by: Nick Piggin \u003cnpiggin@suse.de\u003e\nCc: Chris Mason \u003cchris.mason@oracle.com\u003e\nCc: Dave Chinner \u003cdavid@fromorbit.com\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": "f9d88183f6978da403e8b8b26471760cc884842a",
      "old_mode": 33188,
      "old_path": "mm/filemap.c",
      "new_id": "9c5e6235cc743e37787c124e9f26a9e287ac8c06",
      "new_mode": 33188,
      "new_path": "mm/filemap.c"
    },
    {
      "type": "modify",
      "old_id": "2e847cdcad0eb3ca3c2ada7be31e70bad2a1689a",
      "old_mode": 33188,
      "old_path": "mm/page-writeback.c",
      "new_id": "5edca676e2c32bef6596b1a6e60744605f1604dc",
      "new_mode": 33188,
      "new_path": "mm/page-writeback.c"
    }
  ]
}