MH, If I am not mistaken, then data abort exception is available on arm. Ours is ppc (e6500). Don't think this exception is supported.
*"Write a simple function to perform a CPU write through the linear mapping address."* Can you please elaborate on this? How exactly to do this? Pardon my ignorance. I am not much of a kernel programmer. Thank you for your help so far. Appreciate it. -Regards Nikhil On Fri, Sep 16, 2016 at 4:52 AM, Min-Hua Chen <orca.c...@gmail.com> wrote: > > > On Thu, Sep 15, 2016 at 4:23 PM, Nikhil Utane <nikhil.subscri...@gmail.com > > 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 <orca.c...@gmail.com> >> wrote: >> >>> >>> >>> On Wed, Sep 14, 2016 at 3:17 PM, Nikhil Utane < >>> nikhil.subscri...@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 <orca.c...@gmail.com> >>>> 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.subscri...@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@kernelnewbies.org >>>>>> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >>>>>> >>>>>> >>>>> >>>> >>> >> >
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies