All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Luck, Tony" <tony.luck@intel.com>
To: Borislav Petkov <bp@suse.de>
Cc: Dave Hansen <dave.hansen@intel.com>,
	Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
	x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Yazen Ghannam <yazen.ghannam@amd.com>
Subject: Re: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages
Date: Wed, 21 Jun 2017 10:47:40 -0700	[thread overview]
Message-ID: <20170621174740.npbtg2e4o65tyrss@intel.com> (raw)
In-Reply-To: <20170619180147.qolal6mz2wlrjbxk@pd.tnic>

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 drop a specific address (apart from my own). :-(

> > +#ifdef CONFIG_X86_64
> > +
> > +void arch_unmap_kpfn(unsigned long pfn)
> > +{
> 
> I guess you can move the ifdeffery inside the function.

If I do, then the compiler will emit an empty function. It's only
a couple of bytes for the "ret" ... but why?  I may change it
to:

   #if defined(arch_unmap_kpfn) && defined(CONFIG_MEMORY_FAILURE)

to narrow down further when we need this.

> > +#if PGDIR_SHIFT + 9 < 63 /* 9 because cpp doesn't grok ilog2(PTRS_PER_PGD) */
> 
> Please no side comments.

Ok.

> Also, explain why the build-time check. (Sign-extension going away for VA
> space yadda yadda..., 5 2/3 level paging :-))

Will add.

> Also, I'm assuming this whole "workaround" of sorts should be Intel-only?

I'd assume that other X86 implementations would face similar issues (unless
they have extremely cautious pre-fetchers and/or no speculation).

I'm also assuming that non-X86 architectures that do recovery may want this
too ... hence hooking the arch_unmap_kpfn() function into the generic
memory_failure() code.

> > +	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);
> 
> WARNING: unnecessary whitespace before a quoted newline
> #107: FILE: arch/x86/kernel/cpu/mcheck/mce.c:1089:
> +               pr_warn("Could not invalidate pfn=0x%lx from 1:1 map \n", pfn);

Oops!  Will fix.

-Tony

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: "Luck, Tony" <tony.luck@intel.com>
To: Borislav Petkov <bp@suse.de>
Cc: Dave Hansen <dave.hansen@intel.com>,
	Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
	x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Yazen Ghannam <yazen.ghannam@amd.com>
Subject: Re: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages
Date: Wed, 21 Jun 2017 10:47:40 -0700	[thread overview]
Message-ID: <20170621174740.npbtg2e4o65tyrss@intel.com> (raw)
In-Reply-To: <20170619180147.qolal6mz2wlrjbxk@pd.tnic>

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 drop a specific address (apart from my own). :-(

> > +#ifdef CONFIG_X86_64
> > +
> > +void arch_unmap_kpfn(unsigned long pfn)
> > +{
> 
> I guess you can move the ifdeffery inside the function.

If I do, then the compiler will emit an empty function. It's only
a couple of bytes for the "ret" ... but why?  I may change it
to:

   #if defined(arch_unmap_kpfn) && defined(CONFIG_MEMORY_FAILURE)

to narrow down further when we need this.

> > +#if PGDIR_SHIFT + 9 < 63 /* 9 because cpp doesn't grok ilog2(PTRS_PER_PGD) */
> 
> Please no side comments.

Ok.

> Also, explain why the build-time check. (Sign-extension going away for VA
> space yadda yadda..., 5 2/3 level paging :-))

Will add.

> Also, I'm assuming this whole "workaround" of sorts should be Intel-only?

I'd assume that other X86 implementations would face similar issues (unless
they have extremely cautious pre-fetchers and/or no speculation).

I'm also assuming that non-X86 architectures that do recovery may want this
too ... hence hooking the arch_unmap_kpfn() function into the generic
memory_failure() code.

> > +	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);
> 
> WARNING: unnecessary whitespace before a quoted newline
> #107: FILE: arch/x86/kernel/cpu/mcheck/mce.c:1089:
> +               pr_warn("Could not invalidate pfn=0x%lx from 1:1 map \n", pfn);

Oops!  Will fix.

-Tony

  reply	other threads:[~2017-06-21 17:47 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-16 19:02 [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages Luck, Tony
2017-06-16 19:02 ` Luck, Tony
2017-06-19 18:01 ` Borislav Petkov
2017-06-19 18:01   ` Borislav Petkov
2017-06-21 17:47   ` Luck, Tony [this message]
2017-06-21 17:47     ` Luck, Tony
2017-06-21 19:59     ` Elliott, Robert (Persistent Memory)
2017-06-21 19:59       ` Elliott, Robert (Persistent Memory)
2017-06-21 20:19       ` Luck, Tony
2017-06-21 20:19         ` Luck, Tony
2017-06-22  9:39     ` Borislav Petkov
2017-06-22  9:39       ` Borislav Petkov
2017-06-29 22:11       ` git send-email (w/o Cc: stable) Luck, Tony
2017-06-29 22:11         ` Luck, Tony
2017-06-30  7:08         ` Borislav Petkov
2017-06-30  7:08           ` Borislav Petkov
2017-06-23 22:19     ` [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages Elliott, Robert (Persistent Memory)
2017-06-23 22:19       ` Elliott, Robert (Persistent Memory)
2017-06-23 22:19       ` Elliott, Robert (Persistent Memory)
2017-06-27 22:04       ` Luck, Tony
2017-06-27 22:04         ` Luck, Tony
2017-06-27 22:04         ` Luck, Tony
2017-06-27 22:09         ` Dan Williams
2017-06-27 22:09           ` Dan Williams
2017-08-16 17:18           ` [PATCH-resend] " Luck, Tony
2017-08-16 17:18             ` Luck, Tony
2017-08-17 10:19             ` [tip:x86/mm] x86/mm, " tip-bot for Tony Luck
2017-08-17 22:09             ` [PATCH-resend] " Andrew Morton
2017-08-17 22:09               ` Andrew Morton
2017-08-17 22:29               ` Elliott, Robert (Persistent Memory)
2017-08-17 22:29                 ` Elliott, Robert (Persistent Memory)
2017-08-17 23:32               ` Luck, Tony
2017-08-17 23:32                 ` Luck, Tony
2017-06-21  2:12 ` [PATCH] " Naoya Horiguchi
2017-06-21  2:12   ` Naoya Horiguchi
2017-06-21 17:54   ` Luck, Tony
2017-06-21 17:54     ` Luck, Tony
2017-06-21 19:47     ` Elliott, Robert (Persistent Memory)
2017-06-21 19:47       ` Elliott, Robert (Persistent Memory)
2017-06-21 19:47       ` Elliott, Robert (Persistent Memory)
2017-06-21 20:30       ` Luck, Tony
2017-06-21 20:30         ` Luck, Tony
2017-06-21 20:30         ` Luck, Tony
2017-06-23  5:07         ` Dan Williams
2017-06-23  5:07           ` Dan Williams
2017-06-23  5:07           ` Dan Williams
2017-06-23 20:59           ` Luck, Tony
2017-06-23 20:59             ` Luck, Tony
2017-06-23 20:59             ` Luck, Tony

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170621174740.npbtg2e4o65tyrss@intel.com \
    --to=tony.luck@intel.com \
    --cc=bp@suse.de \
    --cc=dave.hansen@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=x86@kernel.org \
    --cc=yazen.ghannam@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.