)]}'
{
  "commit": "4f43ade45dc57fc3b4a5cb598a6f4916dcc418ba",
  "tree": "5dead721a74290895e48e107b43968adcd42ddc1",
  "parents": [
    "880ca43e5c334c32a8af125e456d1a23314aa416",
    "115d9d77bb0f9152c60b6e8646369fa7f6167593"
  ],
  "author": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Sat Jan 14 10:08:08 2023 -0600"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Sat Jan 14 10:08:08 2023 -0600"
  },
  "message": "Merge tag \u0027fixes-2023-01-14\u0027 of git://git.kernel.org/pub/scm/linux/kernel/git/rppt/memblock\n\nPull memblock fix from Mike Rapoport:\n \"memblock: always release pages to the buddy allocator in\n  memblock_free_late()\n\n  If CONFIG_DEFERRED_STRUCT_PAGE_INIT is enabled, memblock_free_pages()\n  only releases pages to the buddy allocator if they are not in the\n  deferred range. This is correct for free pages (as defined by\n  for_each_free_mem_pfn_range_in_zone()) because free pages in the\n  deferred range will be initialized and released as part of the\n  deferred init process.\n\n  memblock_free_pages() is called by memblock_free_late(), which is used\n  to free reserved ranges after memblock_free_all() has run. All pages\n  in reserved ranges have been initialized at that point, and\n  accordingly, those pages are not touched by the deferred init process.\n\n  This means that currently, if the pages that memblock_free_late()\n  intends to release are in the deferred range, they will never be\n  released to the buddy allocator. They will forever be reserved.\n\n  In addition, memblock_free_pages() calls kmsan_memblock_free_pages(),\n  which is also correct for free pages but is not correct for reserved\n  pages. KMSAN metadata for reserved pages is initialized by\n  kmsan_init_shadow(), which runs shortly before memblock_free_all().\n\n  For both of these reasons, memblock_free_pages() should only be called\n  for free pages, and memblock_free_late() should call\n  __free_pages_core() directly instead.\n\n  One case where this issue can occur in the wild is EFI boot on x86_64.\n  The x86 EFI code reserves all EFI boot services memory ranges via\n  memblock_reserve() and frees them later via memblock_free_late()\n  (efi_reserve_boot_services() and efi_free_boot_services(),\n  respectively).\n\n  If any of those ranges happens to fall within the deferred init range,\n  the pages will not be released and that memory will be unavailable.\n\n  For example, on an Amazon EC2 t3.micro VM (1 GB) booting via EFI:\n\n    v6.2-rc2:\n    Node 0, zone      DMA\n          spanned  4095\n          present  3999\n          managed  3840\n    Node 0, zone    DMA32\n          spanned  246652\n          present  245868\n          managed  178867\n\n    v6.2-rc2 + patch:\n    Node 0, zone      DMA\n          spanned  4095\n          present  3999\n          managed  3840\n    Node 0, zone    DMA32\n          spanned  246652\n          present  245868\n          managed  222816   # +43,949 pages\"\n\n* tag \u0027fixes-2023-01-14\u0027 of git://git.kernel.org/pub/scm/linux/kernel/git/rppt/memblock:\n  mm: Always release pages to the buddy allocator in memblock_free_late().\n",
  "tree_diff": []
}