From mboxrd@z Thu Jan 1 00:00:00 1970 From: orca.chen@gmail.com (Min-Hua Chen) Date: Fri, 16 Sep 2016 07:22:12 +0800 Subject: memblock_reserve or memblock_remove to reserve a page In-Reply-To: References: Message-ID: To: kernelnewbies@lists.kernelnewbies.org List-Id: kernelnewbies.lists.kernelnewbies.org On Thu, Sep 15, 2016 at 4:23 PM, Nikhil Utane wrote: > MH, > > Let me give a bit of background of the issue. > > We are facing an issue where 4 bytes of physical memory is getting > corrupted (set to 0) at a fixed offset. > This offset is always fixed 0x00A4DDC0 (PFN: 0xA4D). The problem manifests > in form of SIGILL for some random user-space application where its text > area is corrupted. At this moment we are not able to identify who is > causing the corruption. While we continue to investigate that (no HW > breakpoint support :(), I thought we could at least mask the problem since > we know the corruption is always occurring at a fixed offset. > Therefore we want to reserve the memory so that kernel does not give it to > anyone. > We tried passing it via kernel command-line parameter (using memblock) but > did not see it working. Finally we modified the function > early_reserve_mem_dt() in file "linux-3.12.19/arch/powerpc/kernel/prom.c" > to directly reserve the memory. > > base1 = 0xA4D000; size1=0x1000; > memblock_reserve(base1, size1); > > To check if reservation is working and to monitor the corruption we wrote > a kernel module that does a ioremap to page 0xA4D. We then poison it with > fixed data. What we found was that, in few runs, this memory was intact and > in few others it would change. We tried both memblock_reserve() as well as > memblock_remove(). Unfortunately we continue to get the SIGILL at the same > offset. > Is there any other way to block a physical memory page? > > ioremap code (relevant lines): > static char* sigill_mon_addr; > #define ADDR_TEST 0xA4D00 > sigill_mon_addr = (char*)ioremap(ADDR_TEST, 4096); > > -Thanks > Nikhil > > Hi Nikhil, How can a reserved page or reserved page with no-map causes a SIGILL? The reserved page should not be allocated to other users. Your applications should be fine even the corruption remains on the reserved page. I think you have to make sure the page is reserved reserved on your system. For a memblock_remove() pages. Write a simple function to perform a CPU write through the linear mapping address. You should get a data abort and make sure that no CPU can access the page. If the corruption remains, the corruption may be caused by other H/W modules. -MH > On Thu, Sep 15, 2016 at 5:35 AM, Min-Hua Chen wrote: > >> >> >> On Wed, Sep 14, 2016 at 3:17 PM, Nikhil Utane < >> nikhil.subscribed at gmail.com> wrote: >> >>> Thank You MH Chen for your response. >>> >>> So does that mean with memblock_reserve(), a kernel module can call >>> phys_to_virt(), create a linear mapping and modify that memory? >>> Where as with memblock_remove(), a kernel module can call ioremap() and >>> then modify the memory? >>> >> >> Not really. It depends on the wether the reserved memory is in a linear >> mapping range. For example, arm32 only creates linear mapping >> within 1GB range because arm32 has only 1GB of kernel space virtual >> memory. arm64 creates linear mapping for a large range >> of memory (depends on ARM64_VA_BITS_xx). >> >> for memblock_remove() memory, You can use ioremap() to access the memory. >> >> >>> What would explain that only in some runs the memory is modified and in >>> some runs it is not (for both the functions)? Shouldn't this >>> reserved/removed memory never be modified unless someone is directly trying >>> to write to that specific page? >>> >>> >> They should not be modified. How do you write to the reserved memory? Can >> you post the source code? >> >> -MH >> >> >> >>> -Regards >>> Nikhil >>> >>> On Sun, Sep 11, 2016 at 6:08 AM, Min-Hua Chen >>> wrote: >>> >>>> Hi Nikhil, >>>> >>>> memblock_reserve() adds a given memory to the "memblock.reserved" list, >>>> it ends up to mark the given range of pages as "reserved". It means the >>>> pages are reserved and will not be allocated to other users. The kernel >>>> still can see the pages, create linear mappings on them, even access them >>>> by linear mappings. >>>> >>>> memblock_remove() removes a given memory from the "memblock.memory" >>>> list, it ends to removed from kernel's memory management system. The memory >>>> will not have page structure, no linear mapping on them. It prevents the >>>> memory from CPU accessing by the linear address. To access the memory (by >>>> CPU), you must use ioremap() to create a mapping to them. >>>> >>>> >>>> MH Chen >>>> >>>> On Fri, Sep 9, 2016 at 5:29 PM, Nikhil Utane < >>>> nikhil.subscribed at gmail.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> I want to reserve a physical memory page with a fixed PFN. I do not >>>>> want this page to be used by anyone else. I am calling memblock_reserve() >>>>> to supposedly reserve the page. I am writing some content into this page. >>>>> What I see is that during some runs the content of this page is modified >>>>> (either fully or sometimes partially). In few runs, I see it as intact. Is >>>>> it expected that even after calling memblock_reserve() the kernel can >>>>> allocate this physical page for any other purpose? How is memblock_remove() >>>>> different from memblock_reserve? I tried reading up but didn't see any >>>>> useful information. What I understood is memblock_remove will completely >>>>> remove from kernel's allocation mechanism. Should I then be using remove >>>>> instead of reserve? >>>>> >>>>> -Thanks >>>>> Nikhil >>>>> >>>>> _______________________________________________ >>>>> Kernelnewbies mailing list >>>>> Kernelnewbies at kernelnewbies.org >>>>> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160916/635648b7/attachment.html