[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AT5PR84MB0082333B55A6823A73C28989ABDA0@AT5PR84MB0082.NAMPRD84.PROD.OUTLOOK.COM>
Date: Wed, 21 Jun 2017 19:59:07 +0000
From: "Elliott, Robert (Persistent Memory)" <elliott@....com>
To: "Luck, Tony" <tony.luck@...el.com>, Borislav Petkov <bp@...e.de>
CC: Dave Hansen <dave.hansen@...el.com>,
Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
"x86@...nel.org" <x86@...nel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Yazen Ghannam <yazen.ghannam@....com>,
"'dan.j.williams@...el.com'" <dan.j.williams@...el.com>,
"Kani, Toshimitsu" <toshi.kani@....com>,
"Vaden, Tom (HPE Server OS Architecture)" <tom.vaden@....com>
Subject: RE: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of
poison pages
> + decoy_addr = (pfn << PAGE_SHIFT) + (PAGE_OFFSET ^ BIT(63));
> +#else
> +#error "no unused virtual bit available"
> +#endif
> +
> + if (set_memory_np(decoy_addr, 1))
> + pr_warn("Could not invalidate pfn=0x%lx from 1:1 map \n", pfn);
Does this patch handle breaking up 512 GiB, 1 GiB or 2 MiB page mappings
if it's just trying to mark a 4 KiB page as bad?
Although the kernel doesn't use MTRRs itself anymore, what if the system
BIOS still uses them for some memory regions, and the bad address falls in
an MTRR region?
---
Robert Elliott, HPE Persistent Memory
Powered by blists - more mailing lists