* memblock_reserve or memblock_remove to reserve a page @ 2016-09-09 1:31 Nikhil Utane 2016-09-09 9:29 ` Nikhil Utane 2016-09-27 10:44 ` Arun Sudhilal 0 siblings, 2 replies; 16+ messages in thread From: Nikhil Utane @ 2016-09-09 1:31 UTC (permalink / raw) To: kernelnewbies 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160909/79f166f2/attachment-0001.html ^ permalink raw reply [flat|nested] 16+ messages in thread
* memblock_reserve or memblock_remove to reserve a page 2016-09-09 1:31 memblock_reserve or memblock_remove to reserve a page Nikhil Utane @ 2016-09-09 9:29 ` Nikhil Utane 2016-09-11 0:38 ` Min-Hua Chen 2016-09-27 10:44 ` Arun Sudhilal 1 sibling, 1 reply; 16+ messages in thread From: Nikhil Utane @ 2016-09-09 9:29 UTC (permalink / raw) To: kernelnewbies 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160909/cabefec7/attachment-0001.html ^ permalink raw reply [flat|nested] 16+ messages in thread
* memblock_reserve or memblock_remove to reserve a page 2016-09-09 9:29 ` Nikhil Utane @ 2016-09-11 0:38 ` Min-Hua Chen 2016-09-14 7:17 ` Nikhil Utane 0 siblings, 1 reply; 16+ messages in thread From: Min-Hua Chen @ 2016-09-11 0:38 UTC (permalink / raw) To: kernelnewbies 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@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/20160911/6ae85950/attachment.html ^ permalink raw reply [flat|nested] 16+ messages in thread
* memblock_reserve or memblock_remove to reserve a page 2016-09-11 0:38 ` Min-Hua Chen @ 2016-09-14 7:17 ` Nikhil Utane 2016-09-15 0:05 ` Min-Hua Chen 0 siblings, 1 reply; 16+ messages in thread From: Nikhil Utane @ 2016-09-14 7:17 UTC (permalink / raw) To: kernelnewbies 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? 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? -Regards Nikhil On Sun, Sep 11, 2016 at 6:08 AM, Min-Hua Chen <orca.chen@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.subscribed@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/20160914/55d7f0c9/attachment.html ^ permalink raw reply [flat|nested] 16+ messages in thread
* memblock_reserve or memblock_remove to reserve a page 2016-09-14 7:17 ` Nikhil Utane @ 2016-09-15 0:05 ` Min-Hua Chen 2016-09-15 8:23 ` Nikhil Utane 0 siblings, 1 reply; 16+ messages in thread From: Min-Hua Chen @ 2016-09-15 0:05 UTC (permalink / raw) To: kernelnewbies On Wed, Sep 14, 2016 at 3:17 PM, Nikhil Utane <nikhil.subscribed@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.chen@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.subscribed@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/20160915/bb1e925f/attachment.html ^ permalink raw reply [flat|nested] 16+ messages in thread
* memblock_reserve or memblock_remove to reserve a page 2016-09-15 0:05 ` Min-Hua Chen @ 2016-09-15 8:23 ` Nikhil Utane 2016-09-15 23:22 ` Min-Hua Chen 0 siblings, 1 reply; 16+ messages in thread From: Nikhil Utane @ 2016-09-15 8:23 UTC (permalink / raw) To: kernelnewbies 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 On Thu, Sep 15, 2016 at 5:35 AM, Min-Hua Chen <orca.chen@gmail.com> wrote: > > > On Wed, Sep 14, 2016 at 3:17 PM, Nikhil Utane <nikhil.subscribed@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.chen@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.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/20160915/c0012922/attachment-0001.html ^ permalink raw reply [flat|nested] 16+ messages in thread
* memblock_reserve or memblock_remove to reserve a page 2016-09-15 8:23 ` Nikhil Utane @ 2016-09-15 23:22 ` Min-Hua Chen 2016-09-16 10:08 ` Nikhil Utane 0 siblings, 1 reply; 16+ messages in thread From: Min-Hua Chen @ 2016-09-15 23:22 UTC (permalink / raw) To: kernelnewbies On Thu, Sep 15, 2016 at 4:23 PM, Nikhil Utane <nikhil.subscribed@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.chen@gmail.com> 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 <orca.chen@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.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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* memblock_reserve or memblock_remove to reserve a page 2016-09-15 23:22 ` Min-Hua Chen @ 2016-09-16 10:08 ` Nikhil Utane 0 siblings, 0 replies; 16+ messages in thread From: Nikhil Utane @ 2016-09-16 10:08 UTC (permalink / raw) To: kernelnewbies 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.chen@gmail.com> wrote: > > > On Thu, Sep 15, 2016 at 4:23 PM, Nikhil Utane <nikhil.subscribed@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.chen@gmail.com> >> 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 <orca.chen@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.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/28eb7b32/attachment.html ^ permalink raw reply [flat|nested] 16+ messages in thread
* memblock_reserve or memblock_remove to reserve a page 2016-09-09 1:31 memblock_reserve or memblock_remove to reserve a page Nikhil Utane 2016-09-09 9:29 ` Nikhil Utane @ 2016-09-27 10:44 ` Arun Sudhilal 2016-09-28 9:11 ` Nikhil Utane 1 sibling, 1 reply; 16+ messages in thread From: Arun Sudhilal @ 2016-09-27 10:44 UTC (permalink / raw) To: kernelnewbies Hello Nikhil, On Fri, Sep 9, 2016 at 7:01 AM, Nikhil Utane <nikhil.subscribed@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 > ^ permalink raw reply [flat|nested] 16+ messages in thread
* memblock_reserve or memblock_remove to reserve a page 2016-09-27 10:44 ` Arun Sudhilal @ 2016-09-28 9:11 ` Nikhil Utane 2016-09-28 9:42 ` Arun Sudhilal 0 siblings, 1 reply; 16+ messages in thread From: Nikhil Utane @ 2016-09-28 9:11 UTC (permalink / raw) To: kernelnewbies 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? -Thanks Nikhil On Tue, Sep 27, 2016 at 4:14 PM, Arun Sudhilal <getarunks@gmail.com> wrote: > Hello Nikhil, > > On Fri, Sep 9, 2016 at 7:01 AM, Nikhil Utane > <nikhil.subscribed@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/20160928/fd57edab/attachment.html ^ permalink raw reply [flat|nested] 16+ messages in thread
* memblock_reserve or memblock_remove to reserve a page 2016-09-28 9:11 ` Nikhil Utane @ 2016-09-28 9:42 ` Arun Sudhilal 2016-09-28 13:25 ` Nikhil Utane 0 siblings, 1 reply; 16+ messages in thread From: Arun Sudhilal @ 2016-09-28 9:42 UTC (permalink / raw) To: kernelnewbies Hello Nikhil, On Wed, Sep 28, 2016 at 2:41 PM, Nikhil Utane <nikhil.subscribed@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@gmail.com> wrote: >> >> Hello Nikhil, >> >> On Fri, Sep 9, 2016 at 7:01 AM, Nikhil Utane >> <nikhil.subscribed@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 >> > > > ^ permalink raw reply [flat|nested] 16+ messages in thread
* memblock_reserve or memblock_remove to reserve a page 2016-09-28 9:42 ` Arun Sudhilal @ 2016-09-28 13:25 ` Nikhil Utane 2016-09-29 5:55 ` Nikhil Utane 2016-10-03 12:32 ` Arun Sudhilal 0 siblings, 2 replies; 16+ messages in thread From: Nikhil Utane @ 2016-09-28 13:25 UTC (permalink / raw) To: kernelnewbies base1 = 0xA4D000; size1=0x1000; memblock_reserve (base1, size1); (In a separate static driver code) request_mem_region_exclusive (0x00A4D000, 4096, "csSIGILL") If a driver requests for a memory region, shouldn't the kernel then not allocate it for any other purpose? -Regards Nikhil On Wed, Sep 28, 2016 at 3:12 PM, Arun Sudhilal <getarunks@gmail.com> wrote: > Hello Nikhil, > > On Wed, Sep 28, 2016 at 2:41 PM, Nikhil Utane > <nikhil.subscribed@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@gmail.com> > wrote: > >> > >> Hello Nikhil, > >> > >> On Fri, Sep 9, 2016 at 7:01 AM, Nikhil Utane > >> <nikhil.subscribed@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/20160928/236b960d/attachment.html ^ permalink raw reply [flat|nested] 16+ messages in thread
* memblock_reserve or memblock_remove to reserve a page 2016-09-28 13:25 ` Nikhil Utane @ 2016-09-29 5:55 ` Nikhil Utane 2016-10-03 12:32 ` Arun Sudhilal 1 sibling, 0 replies; 16+ messages in thread From: Nikhil Utane @ 2016-09-29 5:55 UTC (permalink / raw) To: kernelnewbies Hi, This is the hole that we see in system RAM. Shouldn't the 0xA4D page be out of limit for Linux Kernel? # cat /proc/iomem 00000000-00a4cfff : System RAM 00a4d000-00a4dfff : csSIGILL 00a4e000-bfffffff : System RAM -Regards Nikhil On Wed, Sep 28, 2016 at 6:55 PM, Nikhil Utane <nikhil.subscribed@gmail.com> wrote: > base1 = 0xA4D000; size1=0x1000; > memblock_reserve (base1, size1); > > (In a separate static driver code) > request_mem_region_exclusive (0x00A4D000, 4096, "csSIGILL") > > If a driver requests for a memory region, shouldn't the kernel then not > allocate it for any other purpose? > > -Regards > Nikhil > > On Wed, Sep 28, 2016 at 3:12 PM, Arun Sudhilal <getarunks@gmail.com> > wrote: > >> Hello Nikhil, >> >> On Wed, Sep 28, 2016 at 2:41 PM, Nikhil Utane >> <nikhil.subscribed@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@gmail.com> >> wrote: >> >> >> >> Hello Nikhil, >> >> >> >> On Fri, Sep 9, 2016 at 7:01 AM, Nikhil Utane >> >> <nikhil.subscribed@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/20160929/56a7df6a/attachment.html ^ permalink raw reply [flat|nested] 16+ messages in thread
* memblock_reserve or memblock_remove to reserve a page 2016-09-28 13:25 ` Nikhil Utane 2016-09-29 5:55 ` Nikhil Utane @ 2016-10-03 12:32 ` Arun Sudhilal 2016-10-03 12:45 ` Arun Sudhilal 1 sibling, 1 reply; 16+ messages in thread From: Arun Sudhilal @ 2016-10-03 12:32 UTC (permalink / raw) To: kernelnewbies Hello Nikhil, On Wed, Sep 28, 2016 at 6:55 PM, Nikhil Utane <nikhil.subscribed@gmail.com> wrote: > base1 = 0xA4D000; size1=0x1000; > memblock_reserve (base1, size1); > > (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@gmail.com> wrote: >> >> Hello Nikhil, >> >> On Wed, Sep 28, 2016 at 2:41 PM, Nikhil Utane >> <nikhil.subscribed@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@gmail.com> >> > wrote: >> >> >> >> Hello Nikhil, >> >> >> >> On Fri, Sep 9, 2016 at 7:01 AM, Nikhil Utane >> >> <nikhil.subscribed@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 >> >> > >> > >> > > > ^ permalink raw reply [flat|nested] 16+ messages in thread
* memblock_reserve or memblock_remove to reserve a page 2016-10-03 12:32 ` Arun Sudhilal @ 2016-10-03 12:45 ` Arun Sudhilal 2016-10-04 5:40 ` Nikhil Utane 0 siblings, 1 reply; 16+ messages in thread From: Arun Sudhilal @ 2016-10-03 12:45 UTC (permalink / raw) To: kernelnewbies On Mon, Oct 3, 2016 at 6:02 PM, Arun Sudhilal <getarunks@gmail.com> wrote: > Hello Nikhil, > > On Wed, Sep 28, 2016 at 6:55 PM, Nikhil Utane > <nikhil.subscribed@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@gmail.com> wrote: >>> >>> Hello Nikhil, >>> >>> On Wed, Sep 28, 2016 at 2:41 PM, Nikhil Utane >>> <nikhil.subscribed@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@gmail.com> >>> > wrote: >>> >> >>> >> Hello Nikhil, >>> >> >>> >> On Fri, Sep 9, 2016 at 7:01 AM, Nikhil Utane >>> >> <nikhil.subscribed@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 >>> >> > >>> > >>> > >> >> ^ permalink raw reply [flat|nested] 16+ messages in thread
* memblock_reserve or memblock_remove to reserve a page 2016-10-03 12:45 ` Arun Sudhilal @ 2016-10-04 5:40 ` Nikhil Utane 0 siblings, 0 replies; 16+ messages in thread From: Nikhil Utane @ 2016-10-04 5:40 UTC (permalink / raw) To: kernelnewbies 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@gmail.com> wrote: > On Mon, Oct 3, 2016 at 6:02 PM, Arun Sudhilal <getarunks@gmail.com> wrote: > > Hello Nikhil, > > > > On Wed, Sep 28, 2016 at 6:55 PM, Nikhil Utane > > <nikhil.subscribed@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@gmail.com> > wrote: > >>> > >>> Hello Nikhil, > >>> > >>> On Wed, Sep 28, 2016 at 2:41 PM, Nikhil Utane > >>> <nikhil.subscribed@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@gmail.com> > >>> > wrote: > >>> >> > >>> >> Hello Nikhil, > >>> >> > >>> >> On Fri, Sep 9, 2016 at 7:01 AM, Nikhil Utane > >>> >> <nikhil.subscribed@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 ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2016-10-04 5:40 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-09-09 1:31 memblock_reserve or memblock_remove to reserve a page Nikhil Utane 2016-09-09 9:29 ` Nikhil Utane 2016-09-11 0:38 ` Min-Hua Chen 2016-09-14 7:17 ` Nikhil Utane 2016-09-15 0:05 ` Min-Hua Chen 2016-09-15 8:23 ` Nikhil Utane 2016-09-15 23:22 ` Min-Hua Chen 2016-09-16 10:08 ` Nikhil Utane 2016-09-27 10:44 ` Arun Sudhilal 2016-09-28 9:11 ` Nikhil Utane 2016-09-28 9:42 ` Arun Sudhilal 2016-09-28 13:25 ` Nikhil Utane 2016-09-29 5:55 ` Nikhil Utane 2016-10-03 12:32 ` Arun Sudhilal 2016-10-03 12:45 ` Arun Sudhilal 2016-10-04 5:40 ` Nikhil Utane
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.