Re: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

On Tue, Jun 27, 2017 at 3:04 PM, Luck, Tony wrote: >> > > > +if (set_memory_np(decoy_addr, 1)) >> > > > +pr_warn("Could not invalidate pfn=0x%lx from 1:1 map \n", >> >> Another concept to consider is mapping the page as UC rather than >> completely unmapping it. > > UC would

Re: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

On Tue, Jun 27, 2017 at 3:04 PM, Luck, Tony wrote: >> > > > +if (set_memory_np(decoy_addr, 1)) >> > > > +pr_warn("Could not invalidate pfn=0x%lx from 1:1 map \n", >> >> Another concept to consider is mapping the page as UC rather than >> completely unmapping it. > > UC would also avoid the

RE: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

> > > > +if (set_memory_np(decoy_addr, 1)) > > > > +pr_warn("Could not invalidate pfn=0x%lx from 1:1 map \n", > > Another concept to consider is mapping the page as UC rather than > completely unmapping it. UC would also avoid the speculative prefetch issue. The Vol 3, Section 11.3 SDM says:

RE: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

> > > > +if (set_memory_np(decoy_addr, 1)) > > > > +pr_warn("Could not invalidate pfn=0x%lx from 1:1 map \n", > > Another concept to consider is mapping the page as UC rather than > completely unmapping it. UC would also avoid the speculative prefetch issue. The Vol 3, Section 11.3 SDM says:

RE: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

> > > + if (set_memory_np(decoy_addr, 1)) > > > + pr_warn("Could not invalidate pfn=0x%lx from 1:1 map \n", Another concept to consider is mapping the page as UC rather than completely unmapping it. The uncorrectable error scope could be smaller than a page size, like: * memory ECC width

RE: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

> > > + if (set_memory_np(decoy_addr, 1)) > > > + pr_warn("Could not invalidate pfn=0x%lx from 1:1 map \n", Another concept to consider is mapping the page as UC rather than completely unmapping it. The uncorrectable error scope could be smaller than a page size, like: * memory ECC width

Re: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

On Thu, Jun 22, 2017 at 10:07:18PM -0700, Dan Williams wrote: > On Wed, Jun 21, 2017 at 1:30 PM, Luck, Tony wrote: > >> Persistent memory does have unpoisoning and would require this inverse > >> operation - see drivers/nvdimm/pmem.c pmem_clear_poison() and core.c > >>

Re: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

On Thu, Jun 22, 2017 at 10:07:18PM -0700, Dan Williams wrote: > On Wed, Jun 21, 2017 at 1:30 PM, Luck, Tony wrote: > >> Persistent memory does have unpoisoning and would require this inverse > >> operation - see drivers/nvdimm/pmem.c pmem_clear_poison() and core.c > >> nvdimm_clear_poison(). > >

Re: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

On Wed, Jun 21, 2017 at 1:30 PM, Luck, Tony wrote: >> Persistent memory does have unpoisoning and would require this inverse >> operation - see drivers/nvdimm/pmem.c pmem_clear_poison() and core.c >> nvdimm_clear_poison(). > > Nice. Well this code will need to cooperate with

Re: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

On Wed, Jun 21, 2017 at 1:30 PM, Luck, Tony wrote: >> Persistent memory does have unpoisoning and would require this inverse >> operation - see drivers/nvdimm/pmem.c pmem_clear_poison() and core.c >> nvdimm_clear_poison(). > > Nice. Well this code will need to cooperate with that ... in

Re: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

On Wed, Jun 21, 2017 at 10:47:40AM -0700, Luck, Tony wrote: > I would if I could work out how to use it. From reading the manual > page there seem to be a few options to this, but none of them appear > to just drop a specific address (apart from my own). :-( $ git send-email --to ... --cc ...

Re: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

On Wed, Jun 21, 2017 at 10:47:40AM -0700, Luck, Tony wrote: > I would if I could work out how to use it. From reading the manual > page there seem to be a few options to this, but none of them appear > to just drop a specific address (apart from my own). :-( $ git send-email --to ... --cc ...

RE: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

> Persistent memory does have unpoisoning and would require this inverse > operation - see drivers/nvdimm/pmem.c pmem_clear_poison() and core.c > nvdimm_clear_poison(). Nice. Well this code will need to cooperate with that ... in particular if the page is in an area that can be unpoisoned ...

RE: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

> Persistent memory does have unpoisoning and would require this inverse > operation - see drivers/nvdimm/pmem.c pmem_clear_poison() and core.c > nvdimm_clear_poison(). Nice. Well this code will need to cooperate with that ... in particular if the page is in an area that can be unpoisoned ...

RE: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

>> +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? Yes. The 1:1 mappings start out using the largest supported

RE: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

>> +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? Yes. The 1:1 mappings start out using the largest supported

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

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

RE: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

.de>; Dave Hansen <dave.han...@intel.com>; > x...@kernel.org; linux...@kvack.org; linux-kernel@vger.kernel.org (adding linux-nvdimm list in this reply) > Subject: Re: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 > mappings of poison pages > > On Wed, Jun 21, 2017 at

RE: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

ack.org; linux-kernel@vger.kernel.org (adding linux-nvdimm list in this reply) > Subject: Re: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 > mappings of poison pages > > On Wed, Jun 21, 2017 at 02:12:27AM +, Naoya Horiguchi wrote: > > > We had better

Re: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

On Wed, Jun 21, 2017 at 02:12:27AM +, Naoya Horiguchi wrote: > We had better have a reverse operation of this to cancel the unmapping > when unpoisoning? When we have unpoisoning, we can add something. We don't seem to have an inverse function for "set_memory_np" to just flip the _PRESENT

Re: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

On Wed, Jun 21, 2017 at 02:12:27AM +, Naoya Horiguchi wrote: > We had better have a reverse operation of this to cancel the unmapping > when unpoisoning? When we have unpoisoning, we can add something. We don't seem to have an inverse function for "set_memory_np" to just flip the _PRESENT

Re: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

On Mon, Jun 19, 2017 at 08:01:47PM +0200, Borislav Petkov wrote: > (drop stable from CC) > > You could use git's --suppress-cc= option when sending. I would if I could work out how to use it. From reading the manual page there seem to be a few options to this, but none of them appear to just

Re: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

On Mon, Jun 19, 2017 at 08:01:47PM +0200, Borislav Petkov wrote: > (drop stable from CC) > > You could use git's --suppress-cc= option when sending. I would if I could work out how to use it. From reading the manual page there seem to be a few options to this, but none of them appear to just

Re: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

(drop stable from CC) On Fri, Jun 16, 2017 at 12:02:00PM -0700, Luck, Tony wrote: > From: Tony Luck > > Speculative processor accesses may reference any memory that has a > valid page table entry. While a speculative access won't generate > a machine check, it will log the

Re: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

(drop stable from CC) On Fri, Jun 16, 2017 at 12:02:00PM -0700, Luck, Tony wrote: > From: Tony Luck > > Speculative processor accesses may reference any memory that has a > valid page table entry. While a speculative access won't generate > a machine check, it will log the error in a machine

Re: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

(drop stable from CC) You could use git's --suppress-cc= option when sending. On Fri, Jun 16, 2017 at 12:02:00PM -0700, Luck, Tony wrote: > From: Tony Luck > > Speculative processor accesses may reference any memory that has a > valid page table entry. While a speculative

Re: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

(drop stable from CC) You could use git's --suppress-cc= option when sending. On Fri, Jun 16, 2017 at 12:02:00PM -0700, Luck, Tony wrote: > From: Tony Luck > > Speculative processor accesses may reference any memory that has a > valid page table entry. While a speculative access won't

[PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

From: Tony Luck Speculative processor accesses may reference any memory that has a valid page table entry. While a speculative access won't generate a machine check, it will log the error in a machine check bank. That could cause escalation of a subsequent error since the

[PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

From: Tony Luck Speculative processor accesses may reference any memory that has a valid page table entry. While a speculative access won't generate a machine check, it will log the error in a machine check bank. That could cause escalation of a subsequent error since the overflow bit will be