)]}'
{
  "commit": "39be79c16f2b8eb07dd0d4e965cddfe39cc0534a",
  "tree": "821611221295d47c671ec72e1fb558efcedff03b",
  "parents": [
    "c3b92c8787367a8bb53d57d9789b558f1295cc96"
  ],
  "author": {
    "name": "Jeff Layton",
    "email": "jlayton@redhat.com",
    "time": "Thu Oct 27 23:53:08 2011 +0200"
  },
  "committer": {
    "name": "Christoph Hellwig",
    "email": "hch@serles.lst.de",
    "time": "Fri Oct 28 13:55:08 2011 +0200"
  },
  "message": "vfs: iov_iter: have iov_iter_advance decrement nr_segs appropriately\n\nCurrently, when you call iov_iter_advance, then the pointer to the iovec\narray can be incremented, but it does not decrement the nr_segs value in\nthe iov_iter struct. The result is a iov_iter struct with a nr_segs\nvalue that goes beyond the end of the array.\n\nWhile I\u0027m not aware of anything that\u0027s specifically broken by this, it\nseems odd and a bit dangerous not to decrement that value. If someone\nwere to trust the nr_segs value to be correct, then they could end up\nwalking off the end of the array.\n\nChanging this might also provide some micro-optimization when dealing\nwith the last iovec in an array. Many of the other routines that deal\nwith iov_iter have optimized codepaths when nr_segs \u003d\u003d 1.\n\nCc: Nick Piggin \u003cnpiggin@suse.de\u003e\nSigned-off-by: Jeff Layton \u003cjlayton@redhat.com\u003e\nSigned-off-by: Christoph Hellwig \u003chch@lst.de\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "7771871fa3535d4895ba0d5e92b6a84870980dfb",
      "old_mode": 33188,
      "old_path": "mm/filemap.c",
      "new_id": "5cf820a7c8ec2c1c0e8744eb03750e35b9255ef9",
      "new_mode": 33188,
      "new_path": "mm/filemap.c"
    }
  ]
}