)]}'
{
  "commit": "e81ce85f960c2e26efb5d0802d56c34533edb1bd",
  "tree": "57e1d4ac1704a6311383403f8d11d51bbbd78961",
  "parents": [
    "c69480adeea15883d9459a8adc3da3f6e8cb7a8c"
  ],
  "author": {
    "name": "Joonsoo Kim",
    "email": "js1304@gmail.com",
    "time": "Mon Apr 29 15:07:32 2013 -0700"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Mon Apr 29 15:54:34 2013 -0700"
  },
  "message": "mm, vmalloc: iterate vmap_area_list, instead of vmlist in vread/vwrite()\n\nNow, when we hold a vmap_area_lock, va-\u003evm can\u0027t be discarded.  So we can\nsafely access to va-\u003evm when iterating a vmap_area_list with holding a\nvmap_area_lock.  With this property, change iterating vmlist codes in\nvread/vwrite() to iterating vmap_area_list.\n\nThere is a little difference relate to lock, because vmlist_lock is mutex,\nbut, vmap_area_lock is spin_lock.  It may introduce a spinning overhead\nduring vread/vwrite() is executing.  But, these are debug-oriented\nfunctions, so this overhead is not real problem for common case.\n\nSigned-off-by: Joonsoo Kim \u003cjs1304@gmail.com\u003e\nSigned-off-by: Joonsoo Kim \u003ciamjoonsoo.kim@lge.com\u003e\nCc: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nCc: \"H. Peter Anvin\" \u003chpa@zytor.com\u003e\nCc: Atsushi Kumagai \u003ckumagai-atsushi@mxc.nes.nec.co.jp\u003e\nCc: Chris Metcalf \u003ccmetcalf@tilera.com\u003e\nCc: Dave Anderson \u003canderson@redhat.com\u003e\nCc: Eric Biederman \u003cebiederm@xmission.com\u003e\nCc: Guan Xuetao \u003cgxt@mprc.pku.edu.cn\u003e\nCc: Ingo Molnar \u003cmingo@kernel.org\u003e\nCc: Vivek Goyal \u003cvgoyal@redhat.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": "1bf94ad452b6ab3c47b1ccce4d83422f2cb42cb9",
      "old_mode": 33188,
      "old_path": "mm/vmalloc.c",
      "new_id": "59aa328007b245e05eece706900f2ab3013807d3",
      "new_mode": 33188,
      "new_path": "mm/vmalloc.c"
    }
  ]
}