)]}'
{
  "commit": "40366bd70bbbbf822ca224dfc227a8c8e868c44f",
  "tree": "99dbfa10e6c48632144cd5ad253d939bff392f3f",
  "parents": [
    "c3eeaae9fd736b7f2afbda8d3cbb1cbae06decf3"
  ],
  "author": {
    "name": "Barry Song",
    "email": "song.bao.hua@hisilicon.com",
    "time": "Fri Jul 03 15:15:24 2020 -0700"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Fri Jul 03 16:15:25 2020 -0700"
  },
  "message": "mm/cma.c: use exact_nid true to fix possible per-numa cma leak\n\nCalling cma_declare_contiguous_nid() with false exact_nid for per-numa\nreservation can easily cause cma leak and various confusion.  For example,\nmm/hugetlb.c is trying to reserve per-numa cma for gigantic pages.  But it\ncan easily leak cma and make users confused when system has memoryless\nnodes.\n\nIn case the system has 4 numa nodes, and only numa node0 has memory.  if\nwe set hugetlb_cma\u003d4G in bootargs, mm/hugetlb.c will get 4 cma areas for 4\ndifferent numa nodes.  since exact_nid\u003dfalse in current code, all 4 numa\nnodes will get cma successfully from node0, but hugetlb_cma[1 to 3] will\nnever be available to hugepage will only allocate memory from\nhugetlb_cma[0].\n\nIn case the system has 4 numa nodes, both numa node0\u00262 has memory, other\nnodes have no memory.  if we set hugetlb_cma\u003d4G in bootargs, mm/hugetlb.c\nwill get 4 cma areas for 4 different numa nodes.  since exact_nid\u003dfalse in\ncurrent code, all 4 numa nodes will get cma successfully from node0 or 2,\nbut hugetlb_cma[1] and [3] will never be available to hugepage as\nmm/hugetlb.c will only allocate memory from hugetlb_cma[0] and\nhugetlb_cma[2].  This causes permanent leak of the cma areas which are\nsupposed to be used by memoryless node.\n\nOf cource we can workaround the issue by letting mm/hugetlb.c scan all cma\nareas in alloc_gigantic_page() even node_mask includes node0 only.  that\nmeans when node_mask includes node0 only, we can get page from\nhugetlb_cma[1] to hugetlb_cma[3].  But this will cause kernel crash in\nfree_gigantic_page() while it wants to free page by:\ncma_release(hugetlb_cma[page_to_nid(page)], page, 1 \u003c\u003c order)\n\nOn the other hand, exact_nid\u003dfalse won\u0027t consider numa distance, it might\nbe not that useful to leverage cma areas on remote nodes.  I feel it is\nmuch simpler to make exact_nid true to make everything clear.  After that,\nmemoryless nodes won\u0027t be able to reserve per-numa CMA from other nodes\nwhich have memory.\n\nFixes: cf11e85fc08c (\"mm: hugetlb: optionally allocate gigantic hugepages using cma\")\nSigned-off-by: Barry Song \u003csong.bao.hua@hisilicon.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nAcked-by: Roman Gushchin \u003cguro@fb.com\u003e\nCc: Jonathan Cameron \u003cJonathan.Cameron@huawei.com\u003e\nCc: Aslan Bakirov \u003caslan@fb.com\u003e\nCc: Michal Hocko \u003cmhocko@kernel.org\u003e\nCc: Andreas Schaufler \u003candreas.schaufler@gmx.de\u003e\nCc: Mike Kravetz \u003cmike.kravetz@oracle.com\u003e\nCc: Rik van Riel \u003criel@surriel.com\u003e\nCc: Joonsoo Kim \u003cjs1304@gmail.com\u003e\nCc: Robin Murphy \u003crobin.murphy@arm.com\u003e\nCc: \u003cstable@vger.kernel.org\u003e\nLink: http://lkml.kernel.org/r/20200628074345.27228-1-song.bao.hua@hisilicon.com\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "0463ad2ce06b75eecd52beb61012b1f9721dd3a9",
      "old_mode": 33188,
      "old_path": "mm/cma.c",
      "new_id": "26ecff8188817c598a1c3a1ef788ac0056bddb65",
      "new_mode": 33188,
      "new_path": "mm/cma.c"
    }
  ]
}