Is it possible to relocate a kernel page in physical memory?

Is it possible to relocate a kernel page in physical memory?

[Arvid Brodin]

I want to do memory checks (? la memtest86) on a running system. I know using
ECC memory would be a better approach, but unfortunately that is not an option
in this case. Also, this seems like an excellent opportunity to learn more
about the memory system in Linux.

This is on a AVR32 embedded system, BTW.

One approach is to use the AVR32's built-in SRAM pages to store and run kernel
code that periodically takes a spinlock and checks a small part of the physical
memory, before writing back its original value. This has numerous problems,
among others that the SRAM pages are also used by the power management code on
these processors. And of course, it's not exactly portable...

Another approach is to run the test as a part of the normal kernel. For memory
allocated by user processes, this should be pretty straight-forward (I think):
just copy the page data to another physical page and modify the page tables
(right?). When in comes to the kernel, I might be able to skip testing of the
(read-only) text segment by doing md5summing over it instead (would this have
any drawbacks)? But how would one test writable pages allocated by the kernel?

Is there a way to "relocate" a kernel page in physical memory?

-- 
Arvid Brodin
Enea Services Stockholm AB

Is it possible to relocate a kernel page in physical memory?

[Jeff Haran]

> -----Original Message-----
> From: kernelnewbies-bounces at kernelnewbies.org [mailto:kernelnewbies-
> bounces at kernelnewbies.org] On Behalf Of Arvid Brodin
> Sent: Friday, August 19, 2011 10:35 AM
> To: kernelnewbies at kernelnewbies.org
> Subject: Is it possible to relocate a kernel page in physical memory?
> 
> I want to do memory checks (? la memtest86) on a running system. I know
> using
> ECC memory would be a better approach, but unfortunately that is not an
> option
> in this case. Also, this seems like an excellent opportunity to learn more
> about the memory system in Linux.
> 
> This is on a AVR32 embedded system, BTW.
> 
> One approach is to use the AVR32's built-in SRAM pages to store and run
> kernel
> code that periodically takes a spinlock and checks a small part of the physical
> memory, before writing back its original value. This has numerous problems,
> among others that the SRAM pages are also used by the power management
> code on
> these processors. And of course, it's not exactly portable...
> 
> Another approach is to run the test as a part of the normal kernel. For
> memory
> allocated by user processes, this should be pretty straight-forward (I think):
> just copy the page data to another physical page and modify the page tables
> (right?). When in comes to the kernel, I might be able to skip testing of the
> (read-only) text segment by doing md5summing over it instead (would this
> have
> any drawbacks)? But how would one test writable pages allocated by the
> kernel?
> 
> Is there a way to "relocate" a kernel page in physical memory?
> 
> --
> Arvid Brodin
> Enea Services Stockholm AB
> 

I can't say that I understand why you want to do what you've described, but to the extent that it sounds a bit like what the EDAC driver has to do to in order to scrub single bit ECC errors from a page when they are detected by an ECC enabled memory controller (read the page, write it back), you might want to look at the EDAC driver and see how it does what it does.

See the code in drivers/edac.

Is it possible to relocate a kernel page in physical memory?

[Arvid Brodin]

Jeff Haran wrote:
>> -----Original Message-----
>> From: kernelnewbies-bounces at kernelnewbies.org [mailto:kernelnewbies-
>> bounces at kernelnewbies.org] On Behalf Of Arvid Brodin
>> Sent: Friday, August 19, 2011 10:35 AM
>> To: kernelnewbies at kernelnewbies.org
>> Subject: Is it possible to relocate a kernel page in physical memory?
>>
>> I want to do memory checks (? la memtest86) on a running system. I know
>> using
>> ECC memory would be a better approach, but unfortunately that is not an
>> option
>> in this case. Also, this seems like an excellent opportunity to learn more
>> about the memory system in Linux.
>>
>> This is on a AVR32 embedded system, BTW.
>>
>> One approach is to use the AVR32's built-in SRAM pages to store and run
>> kernel
>> code that periodically takes a spinlock and checks a small part of the physical
>> memory, before writing back its original value. This has numerous problems,
>> among others that the SRAM pages are also used by the power management
>> code on
>> these processors. And of course, it's not exactly portable...
>>
>> Another approach is to run the test as a part of the normal kernel. For
>> memory
>> allocated by user processes, this should be pretty straight-forward (I think):
>> just copy the page data to another physical page and modify the page tables
>> (right?). When in comes to the kernel, I might be able to skip testing of the
>> (read-only) text segment by doing md5summing over it instead (would this
>> have
>> any drawbacks)? But how would one test writable pages allocated by the
>> kernel?
>>
>> Is there a way to "relocate" a kernel page in physical memory?
>>
>> --
>> Arvid Brodin
>> Enea Services Stockholm AB
>>
> 
> I can't say that I understand why you want to do what you've described, but to the extent that it sounds a bit like what the EDAC driver has to do to in order to scrub single bit ECC errors from a page when they are detected by an ECC enabled memory controller (read the page, write it back), you might want to look at the EDAC driver and see how it does what it does.
> 
> See the code in drivers/edac.
> 

Thanks, I'll check that out!

Actually I'm not sure of all the details myself, but this is a system that will
probably run continually for many years, and that is somewhat critical. So we
want to try to catch any problems with it as soon as possible (to be able to
replace it if needs be). It's not necessarily a high-availability system, but
it should not crash without detection, nor fail in undetectable ways.

What I want to do is write bit-patterns to SDRAM, then read them back and make
sure what I read is what I wrote. And I need to do this over all of the
physical RAM.

Do you think this is completely without reason? ;) (If so, why?)

-- 
Arvid Brodin
Enea Services Stockholm AB

Is it possible to relocate a kernel page in physical memory?

[Jeff Haran]

> -----Original Message-----
> From: Arvid Brodin [mailto:arvid.brodin at enea.com]
> Sent: Friday, August 19, 2011 11:51 AM
> To: Jeff Haran
> Cc: kernelnewbies at kernelnewbies.org
> Subject: Re: Is it possible to relocate a kernel page in physical memory?
> 
> Jeff Haran wrote:
> >> -----Original Message-----
> >> From: kernelnewbies-bounces at kernelnewbies.org
> [mailto:kernelnewbies-
> >> bounces at kernelnewbies.org] On Behalf Of Arvid Brodin
> >> Sent: Friday, August 19, 2011 10:35 AM
> >> To: kernelnewbies at kernelnewbies.org
> >> Subject: Is it possible to relocate a kernel page in physical memory?
> >>
> >> I want to do memory checks (? la memtest86) on a running system. I
> know
> >> using
> >> ECC memory would be a better approach, but unfortunately that is not an
> >> option
> >> in this case. Also, this seems like an excellent opportunity to learn more
> >> about the memory system in Linux.
> >>
> >> This is on a AVR32 embedded system, BTW.
> >>
> >> One approach is to use the AVR32's built-in SRAM pages to store and run
> >> kernel
> >> code that periodically takes a spinlock and checks a small part of the
> physical
> >> memory, before writing back its original value. This has numerous
> problems,
> >> among others that the SRAM pages are also used by the power
> management
> >> code on
> >> these processors. And of course, it's not exactly portable...
> >>
> >> Another approach is to run the test as a part of the normal kernel. For
> >> memory
> >> allocated by user processes, this should be pretty straight-forward (I
> think):
> >> just copy the page data to another physical page and modify the page
> tables
> >> (right?). When in comes to the kernel, I might be able to skip testing of
> the
> >> (read-only) text segment by doing md5summing over it instead (would
> this
> >> have
> >> any drawbacks)? But how would one test writable pages allocated by the
> >> kernel?
> >>
> >> Is there a way to "relocate" a kernel page in physical memory?
> >>
> >> --
> >> Arvid Brodin
> >> Enea Services Stockholm AB
> >>
> >
> > I can't say that I understand why you want to do what you've described,
> but to the extent that it sounds a bit like what the EDAC driver has to do to in
> order to scrub single bit ECC errors from a page when they are detected by
> an ECC enabled memory controller (read the page, write it back), you might
> want to look at the EDAC driver and see how it does what it does.
> >
> > See the code in drivers/edac.
> >
> 
> Thanks, I'll check that out!
> 
> Actually I'm not sure of all the details myself, but this is a system that will
> probably run continually for many years, and that is somewhat critical. So we
> want to try to catch any problems with it as soon as possible (to be able to
> replace it if needs be). It's not necessarily a high-availability system, but
> it should not crash without detection, nor fail in undetectable ways.
> 
> What I want to do is write bit-patterns to SDRAM, then read them back and
> make
> sure what I read is what I wrote. And I need to do this over all of the
> physical RAM.

OK, now I understand what you are proposing. 

> Do you think this is completely without reason? ;) (If so, why?)

No, it makes sense. What the EDAC driver does it not quite the same, but I suspect looking at it will be instructive nevertheless. The tricky part is going to be making sure that the memory you are testing is not being used by the code doing the testing.
 
> --
> Arvid Brodin
> Enea Services Stockholm AB