)]}'
{
  "commit": "3a4207e2c4deedd2101715de90c786615d3de912",
  "tree": "8dccd574c552094ece3caf03ed427a155eccc647",
  "parents": [
    "8d744330229c91ebacccbd3c6fe16d2f451fa369"
  ],
  "author": {
    "name": "Vlastimil Babka",
    "email": "vbabka@suse.cz",
    "time": "Wed Nov 12 10:29:52 2025 +0100"
  },
  "committer": {
    "name": "Vlastimil Babka",
    "email": "vbabka@suse.cz",
    "time": "Thu Nov 13 19:53:23 2025 +0100"
  },
  "message": "mm/mempool: fix poisoning order\u003e0 pages with HIGHMEM\n\nThe kernel test has reported:\n\n  BUG: unable to handle page fault for address: fffba000\n  #PF: supervisor write access in kernel mode\n  #PF: error_code(0x0002) - not-present page\n  *pde \u003d 03171067 *pte \u003d 00000000\n  Oops: Oops: 0002 [#1]\n  CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G                T   6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE  a1d066dfe789f54bc7645c7989957d2bdee593ca\n  Tainted: [T]\u003dRANDSTRUCT\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n  EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17)\n  Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 \u003cf3\u003e aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56\n  EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b\n  ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8\n  DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287\n  CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690\n  Call Trace:\n   poison_element (mm/mempool.c:83 mm/mempool.c:102)\n   mempool_init_node (mm/mempool.c:142 mm/mempool.c:226)\n   mempool_init_noprof (mm/mempool.c:250 (discriminator 1))\n   ? mempool_alloc_pages (mm/mempool.c:640)\n   bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8))\n   ? mempool_alloc_pages (mm/mempool.c:640)\n   do_one_initcall (init/main.c:1283)\n\nChristoph found out this is due to the poisoning code not dealing\nproperly with CONFIG_HIGHMEM because only the first page is mapped but\nthen the whole potentially high-order page is accessed.\n\nThis went unnoticed for years probably because nobody has yet used a\nmempool for order\u003e0 pages before the new block code in -next.\n\nWe could give up on HIGHMEM here, but it\u0027s straightforward to fix this\nwith a loop that\u0027s mapping, poisoning or checking and unmapping\nindividual pages.\n\nReported-by: kernel test robot \u003coliver.sang@intel.com\u003e\nCloses: https://lore.kernel.org/oe-lkp/202511111411.9ebfa1ba-lkp@intel.com\nAnalyzed-by: Christoph Hellwig \u003chch@lst.de\u003e\nFixes: bdfedb76f4f5 (\"mm, mempool: poison elements backed by slab allocator\")\nTested-by: kernel test robot \u003coliver.sang@intel.com\u003e\nSigned-off-by: Vlastimil Babka \u003cvbabka@suse.cz\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "1c38e873e546fadcc594f041874eb42774e3df16",
      "old_mode": 33188,
      "old_path": "mm/mempool.c",
      "new_id": "d7bbf1189db9f05d0e7d8eb0cc7bcc87b655d2a7",
      "new_mode": 33188,
      "new_path": "mm/mempool.c"
    }
  ]
}