)]}'
{
  "commit": "35f2d16bb9ace0fb2671b8232839944ad9057c6f",
  "tree": "763610b668cb62664b55a838488e96dad829a9b0",
  "parents": [
    "e8143ccb6b501f78bb95d9c5ee100d18423008cf"
  ],
  "author": {
    "name": "Takuya Yoshikawa",
    "email": "yoshikawa.takuya@oss.ntt.co.jp",
    "time": "Mon Aug 20 18:35:39 2012 +0900"
  },
  "committer": {
    "name": "Avi Kivity",
    "email": "avi@redhat.com",
    "time": "Wed Aug 22 15:27:13 2012 +0300"
  },
  "message": "KVM: MMU: Fix mmu_shrink() so that it can free mmu pages as intended\n\nAlthough the possible race described in\n\n  commit 85b7059169e128c57a3a8a3e588fb89cb2031da1\n  KVM: MMU: fix shrinking page from the empty mmu\n\nwas correct, the real cause of that issue was a more trivial bug of\nmmu_shrink() introduced by\n\n  commit 1952639665e92481c34c34c3e2a71bf3e66ba362\n  KVM: MMU: do not iterate over all VMs in mmu_shrink()\n\nHere is the bug:\n\n\tif (kvm-\u003earch.n_used_mmu_pages \u003e 0) {\n\t\tif (!nr_to_scan--)\n\t\t\tbreak;\n\t\tcontinue;\n\t}\n\nWe skip VMs whose n_used_mmu_pages is not zero and try to shrink others:\nin other words we try to shrink empty ones by mistake.\n\nThis patch reverses the logic so that mmu_shrink() can free pages from\nthe first VM whose n_used_mmu_pages is not zero.  Note that we also add\ncomments explaining the role of nr_to_scan which is not practically\nimportant now, hoping this will be improved in the future.\n\nSigned-off-by: Takuya Yoshikawa \u003cyoshikawa.takuya@oss.ntt.co.jp\u003e\nCc: Gleb Natapov \u003cgleb@redhat.com\u003e\nSigned-off-by: Avi Kivity \u003cavi@redhat.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "01ca00423938515cfe43781403e90bfb84929fc3",
      "old_mode": 33188,
      "old_path": "arch/x86/kvm/mmu.c",
      "new_id": "7fbd0d273ea83dbec4a330fcb6d14a8ab46462b0",
      "new_mode": 33188,
      "new_path": "arch/x86/kvm/mmu.c"
    }
  ]
}