* Brandeburg, Jesse  wrote:
> From: Bruce Allan

quoted text
>

> Export set_memory_ro() and set_memory_rw() calls. Soon to be used

> by e1000e.

>

> Signed-off-by: Bruce Allan

> Signed-off-by: Jesse Brandeburg

> ---

>

>  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 
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

--

unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

the body of a message to majordomo@vger.kernel.org

More majordomo info at  http://vger.kernel.org/majordomo-info.html

Please read the FAQ at  http://www.tux.org/lkml/