Re: e1000e NVM corruption issue status

[Ingo Molnar <mingo@elte.hu>]

* Brandeburg, Jesse <jesse.brandeburg@intel.com> wrote:

> From: Bruce Allan <bruce.w.allan@intel.com>
> 
> Export set_memory_ro() and set_memory_rw() calls. Soon to be used
> by e1000e.
> 
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
> ---
> 
>  arch/x86/mm/pageattr.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
> index 43e2f84..0991e15 100644
> --- a/arch/x86/mm/pageattr.c
> +++ b/arch/x86/mm/pageattr.c
> @@ -906,11 +906,13 @@ int set_memory_ro(unsigned long addr, int numpages)
>  {
>  	return change_page_attr_clear(addr, numpages, __pgprot(_PAGE_RW));
>  }
> +EXPORT_SYMBOL(set_memory_ro);
>  
>  int set_memory_rw(unsigned long addr, int numpages)
>  {
>  	return change_page_attr_set(addr, numpages, __pgprot(_PAGE_RW));
>  }
> +EXPORT_SYMBOL(set_memory_rw);

that's fine, as long as you make it kernel-internal EXPORT_SYMBOL_GPL():

  Acked-by: Ingo Molnar <mingo@elte.hu>

feel free to push that bit via the networking tree(s) whenever you think 
you'd like to push it. We can queue it up in the x86 tree too - it's a 
useful debug facility for critical resources.

one other possible angle beyond these current theories of user-space PCI 
BAR corruption (perhaps) and racy in-kernel corruption (less likely) is 
PAT and conflicting caching attributes.

But that too is in the race category IMO (while this corruption seems to 
trigger straight away on the affected boxes) and the CPUs that saw these 
corruptions should triple fault if the OS creates conflicting cache 
attributes.

	Ingo