memblock_reserve or memblock_remove to reserve a page

[Nikhil Utane]

Hi Arun,

Thanks for your responses. Here's some additional details.

We were calling memblock_reserve() very early in the game when even kernel
is calling to do the reservation.
The reason I think memblock_reserve() was not working was that kernel was
already reserving a big chunk (0 to 0xbfffffff). Our page which was falling
in between would become a no-op.
Call to request_mem_region() fails when the page is already reserved by the
kernel.
It's only when we removed it does the call to request_mem_region() succeed.

About the corruption, What my understanding was, it cannot be caused by any
application, since it will not have any privilege to modify the text
segment. But are you saying that any application can still do it via
/dev/mem route? In our system we have couple of other suspects as well
which can cause such a corruption (DMA, DSP etc), It is unlike a standard
linux machine running some application.

Another question, will the removed page be off-limits to the buddy
allocator as well if we call it soon enough?
(That's what it looks like based on our tests but would be good to get a
confirmation of it)
Since the problem is not easy to reproduce, it's difficult to be certain
that we have successfully avoided the corruption. (We ran 300+ iterations
of a test successfully. The problem could be seen within 20-80 iterations)

-Thanks
Nikhil

On Mon, Oct 3, 2016 at 6:15 PM, Arun Sudhilal <getarunks at gmail.com> wrote:

> On Mon, Oct 3, 2016 at 6:02 PM, Arun Sudhilal <getarunks at gmail.com> wrote:
> > Hello Nikhil,
> >
> > On Wed, Sep 28, 2016 at 6:55 PM, Nikhil Utane
> > <nikhil.subscribed at gmail.com> wrote:
> >> base1 = 0xA4D000; size1=0x1000;
> >> memblock_reserve (base1, size1);
>
> Most probably your memblock_reserve() function is not affecting. It
> depends on when you are calling this function as explained
> earlier(after or before hand-off to buddy allocator).
>
> Lets say you are calling it pretty late and if
> CONFIG_ARCH_DISCARD_MEMBLOCK is disabled in your build,
> memblock_reserve() just go ahead and modifies the memblock structures
> but does not have any effect as buddy allocator has already taken
> control of memory management. That might be the reason you were not
> able to make this page reserved.
>
> >>
> >> (In a separate static driver code)
> >> request_mem_region_exclusive (0x00A4D000, 4096, "csSIGILL")
> >
> > Thanks for details. Looks strange.
> > One possible case I can think of is, when you use
> > request_mem_region_exclusive, user space cannot access it using
> > /dev/mem. May be any of your user space task is corrupting this region
> > before. now he is not able to access this location because you have
> > marked it as EXCLUSIVE for kernel.
> >
> >>
> >> If a driver requests for a memory region, shouldn't the kernel then not
> >> allocate it for any other purpose?
> > To remove pages from kernel allocation, you need to have only
> > successful invocation of memblock_reserve() function.
> >
> > Regards,
> > Arun
> >
> >>
> >> -Regards
> >> Nikhil
> >>
> >> On Wed, Sep 28, 2016 at 3:12 PM, Arun Sudhilal <getarunks at gmail.com>
> wrote:
> >>>
> >>> Hello Nikhil,
> >>>
> >>> On Wed, Sep 28, 2016 at 2:41 PM, Nikhil Utane
> >>> <nikhil.subscribed at gmail.com> wrote:
> >>> > Arun,
> >>> >
> >>> > What seems to have done the trick is calling memblock_remove()
> followed
> >>> > by a
> >>> > call to request_mem_region(). This creates a hole which can be
> confirmed
> >>> > in
> >>> > the output of /proc/iomem.
> >>> >
> >>> > Do you see any issue with this approach?
> >>>
> >>> I really don't know how it works for you. Marking address of a page as
> >>> iomem.  How buddy allocator ignores this page?
> >>> request_mem_region() is a way of managing IO resource memory, to avoid
> >>> two drivers using same IO memory. It has not relation with buddy
> >>> allocator.
> >>>
> >>> Can you post code snippet?
> >>>
> >>> Regards,
> >>> Arun
> >>>
> >>> >
> >>> > -Thanks
> >>> > Nikhil
> >>> >
> >>> > On Tue, Sep 27, 2016 at 4:14 PM, Arun Sudhilal <getarunks at gmail.com>
> >>> > wrote:
> >>> >>
> >>> >> Hello Nikhil,
> >>> >>
> >>> >> On Fri, Sep 9, 2016 at 7:01 AM, Nikhil Utane
> >>> >> <nikhil.subscribed at gmail.com> wrote:
> >>> >> > 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?
> >>> >>
> >>> >> when a DT entry is added to  #reserved-memory node, what
> >>> >> drivers/of/fdt.c does is to call memblock_remove() and
> >>> >> memblock_reserve().
> >>> >> This happens after the memblock driver is initialized but before
> buddy
> >>> >> allocator up. Did you try this approach? This should work for you.
> >>> >>
> >>> >> Only option once the kernel boot is complete is to try out the
> >>> >> technique what mm/memory_hotplug.c does while offline memory.
> >>> >> isolate_page_range and then migrate.
> >>> >>
> >>> >> Regards,
> >>> >> Arun
> >>> >>
> >>> >>
> >>> >> >
> >>> >> > -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/20161004/96569efb/attachment-0001.html