memblock_reserve or memblock_remove to reserve a page

Nikhil Utane nikhil.subscribed at
Fri Sep 16 06:08:22 EDT 2016


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


On Fri, Sep 16, 2016 at 4:52 AM, Min-Hua Chen <orca.chen at> wrote:

> On Thu, Sep 15, 2016 at 4:23 PM, Nikhil Utane <nikhil.subscribed at
> > 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.chen at>
>> wrote:
>>> On Wed, Sep 14, 2016 at 3:17 PM, Nikhil Utane <
>>> nikhil.subscribed at> 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.chen at>
>>>> 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> 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
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Kernelnewbies mailing list