)]}'
{
  "commit": "66520ebc2df3fe52eb4792f8101fac573b766baf",
  "tree": "cc31359fa406833d946eff89ee8804b18e81c673",
  "parents": [
    "e8c57d40519d7226acb8e662f3ab496202ebc7a6"
  ],
  "author": {
    "name": "Jacob Shin",
    "email": "jacob.shin@amd.com",
    "time": "Fri Nov 16 19:38:52 2012 -0800"
  },
  "committer": {
    "name": "H. Peter Anvin",
    "email": "hpa@linux.intel.com",
    "time": "Sat Nov 17 11:59:14 2012 -0800"
  },
  "message": "x86, mm: Only direct map addresses that are marked as E820_RAM\n\nCurrently direct mappings are created for [ 0 to max_low_pfn\u003c\u003cPAGE_SHIFT )\nand [ 4GB to max_pfn\u003c\u003cPAGE_SHIFT ), which may include regions that are not\nbacked by actual DRAM. This is fine for holes under 4GB which are covered\nby fixed and variable range MTRRs to be UC. However, we run into trouble\non higher memory addresses which cannot be covered by MTRRs.\n\nOur system with 1TB of RAM has an e820 that looks like this:\n\n BIOS-e820: [mem 0x0000000000000000-0x00000000000983ff] usable\n BIOS-e820: [mem 0x0000000000098400-0x000000000009ffff] reserved\n BIOS-e820: [mem 0x00000000000d0000-0x00000000000fffff] reserved\n BIOS-e820: [mem 0x0000000000100000-0x00000000c7ebffff] usable\n BIOS-e820: [mem 0x00000000c7ec0000-0x00000000c7ed7fff] ACPI data\n BIOS-e820: [mem 0x00000000c7ed8000-0x00000000c7ed9fff] ACPI NVS\n BIOS-e820: [mem 0x00000000c7eda000-0x00000000c7ffffff] reserved\n BIOS-e820: [mem 0x00000000fec00000-0x00000000fec0ffff] reserved\n BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved\n BIOS-e820: [mem 0x00000000fff00000-0x00000000ffffffff] reserved\n BIOS-e820: [mem 0x0000000100000000-0x000000e037ffffff] usable\n BIOS-e820: [mem 0x000000e038000000-0x000000fcffffffff] reserved\n BIOS-e820: [mem 0x0000010000000000-0x0000011ffeffffff] usable\n\nand so direct mappings are created for huge memory hole between\n0x000000e038000000 to 0x0000010000000000. Even though the kernel never\ngenerates memory accesses in that region, since the page tables mark\nthem incorrectly as being WB, our (AMD) processor ends up causing a MCE\nwhile doing some memory bookkeeping/optimizations around that area.\n\nThis patch iterates through e820 and only direct maps ranges that are\nmarked as E820_RAM, and keeps track of those pfn ranges. Depending on\nthe alignment of E820 ranges, this may possibly result in using smaller\nsize (i.e. 4K instead of 2M or 1G) page tables.\n\n-v2: move changes from setup.c to mm/init.c, also use for_each_mem_pfn_range\n\tinstead.  - Yinghai Lu\n-v3: add calculate_all_table_space_size() to get correct needed page table\n\tsize. - Yinghai Lu\n-v4: fix add_pfn_range_mapped() to get correct max_low_pfn_mapped when\n     mem map does have hole under 4g that is found by Konard on xen\n     domU with 8g ram. - Yinghai\n\nSigned-off-by: Jacob Shin \u003cjacob.shin@amd.com\u003e\nLink: http://lkml.kernel.org/r/1353123563-3103-16-git-send-email-yinghai@kernel.org\nSigned-off-by: Yinghai Lu \u003cyinghai@kernel.org\u003e\nReviewed-by: Pekka Enberg \u003cpenberg@kernel.org\u003e\nSigned-off-by: H. Peter Anvin \u003chpa@linux.intel.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "45aae6e5f6493dd94c163d9889eeedcdad003bc0",
      "old_mode": 33188,
      "old_path": "arch/x86/include/asm/page_types.h",
      "new_id": "54c97879195e7c5137d2a45fbda51c40a1c41be2",
      "new_mode": 33188,
      "new_path": "arch/x86/include/asm/page_types.h"
    },
    {
      "type": "modify",
      "old_id": "bd52f9da17cc8d0e0541dd6f54783ccfa88d888c",
      "old_mode": 33188,
      "old_path": "arch/x86/kernel/setup.c",
      "new_id": "68dffeceb1935303c1fc86e4eac9a53798c604c0",
      "new_mode": 33188,
      "new_path": "arch/x86/kernel/setup.c"
    },
    {
      "type": "modify",
      "old_id": "7b961d0b138961fbd55ef5128816a1cdeaa19ab7",
      "old_mode": 33188,
      "old_path": "arch/x86/mm/init.c",
      "new_id": "bb44e9f2cc494e9ee44bf0ca8647e7dd2d20c2bb",
      "new_mode": 33188,
      "new_path": "arch/x86/mm/init.c"
    },
    {
      "type": "modify",
      "old_id": "3baff255adac6472570298d7e9ee60df75e93dfc",
      "old_mode": 33188,
      "old_path": "arch/x86/mm/init_64.c",
      "new_id": "32c7e3847cf619ec28f9732df1879535997b7153",
      "new_mode": 33188,
      "new_path": "arch/x86/mm/init_64.c"
    }
  ]
}