arm L_PTE_XXX entry addition for Debugging purpose

bill4carson bill4carson at gmail.com
Thu Aug 2 05:28:44 EDT 2012



On 2012年08月02日 17:03, Dhyan wrote:
> Dear Bill,
>
> What i found from experimenting on arm Linux kernel is ,after every
> access if i clear the _PG_ACCESS bit of the pte (using
> /proc/<pid>/clear_refs),the next write also will come to kernel
> (handle_pte_fault).But I dont know whether my clearing action causing
> any bad impact on any other system.
>

592 static int clear_refs_pte_range(pmd_t *pmd, unsigned long addr,
  593                 unsigned long end, struct mm_walk *walk)
  594 {
  595     struct vm_area_struct *vma = walk->private;
  596     pte_t *pte, ptent;
  597     spinlock_t *ptl;
  598     struct page *page;
  599
  600     split_huge_page_pmd(walk->mm, pmd);
  601     if (pmd_trans_unstable(pmd))
  602         return 0;
  603
  604     pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, &ptl);
  605     for (; addr != end; pte++, addr += PAGE_SIZE) {
  606         ptent = *pte;
  607         if (!pte_present(ptent))
  608             continue;
  609
  610         page = vm_normal_page(vma, addr, ptent);
  611         if (!page)
  612             continue;
  613
  614         /* Clear accessed and referenced bits. */
  615         ptep_test_and_clear_young(vma, addr, pte);
                    ^^^^^^^^^^^^
For arm, it clear all the corresponding pte entries.
that's why you got second page fault.

Again, I don't understand your original purpose.

> --
> Thanks
> Dhyan
>
> On Thu, Aug 2, 2012 at 2:12 PM, bill4carson <bill4carson at gmail.com
> <mailto:bill4carson at gmail.com>> wrote:
>
>
>
>     On 2012年08月01日 12:53, Dhyan wrote:
>
>         Dear Bill,
>
>         Thank you for spending your valuable time for  understanding and
>         answering my queries !!!
>
>         I was trying to apply some garbage collection algorithm on this
>         dumped
>         pages,thats why i want only the written pages.
>
>         Sorry to ask,but is there any other good way to find the written
>         pages
>         of a user process?
>
>
>     Only the first wirte trigger page fault, which setup the page table by
>     grabbing a physical page to backup virtual address page. After this,
>     all write into that page goes like wind without any kernel interference
>     anymore.
>
>
>     But my hunch tell me what you want is to track every user space write
>     operation.
>
>
>
>         --
>         Thanks
>         Dhyan
>
>         On Wed, Aug 1, 2012 at 7:38 AM, bill4carson
>         <bill4carson at gmail.com <mailto:bill4carson at gmail.com>
>         <mailto:bill4carson at gmail.com <mailto:bill4carson at gmail.com>>__>
>         wrote:
>
>
>
>              On 2012年07月31日 17:20, Dhyan wrote:
>
>                  Thank You Bill !!!
>
>                  I dont know my approach is correct or not,But the
>         actual purpose
>                  was to
>                  dump only  written pages of a user process using a kernel
>                  module.I have
>                  a kernel thread which will dump user process memory in
>         specific
>                  interval.So i thought of updating this flag
>         (L_PTE_DEBUG) from
>                  handle_pte_fault and clear from my clear thread so that
>         i can
>                  dump only
>                  the written pages after my last dump.
>
>
>              Yes, you can do that, only if your accounting memory
>         doesn't get swapped
>              out.
>
>              If I understand correctly, when writing a page, you mark
>         corresponding
>              linux pte entry with L_PTE_DEBUG. Then your kernel module
>         periodically
>              loops all linux pte table, find pte entry marked with
>         L_PTE_DEBUG.....
>
>              I don't think it's wise to do so, you have 768 1st level
>         pgd entries
>              for user space, followed by 256 pte entries with each pgd
>         entry.
>              it's much slower to find out the right one.
>
>              moreover, you probably need to remap those L_PTE_DEBUG
>         physical pages
>              into your own current process address space. IMHO, I don't
>         follow
>              such idea could be feasible.
>
>
>
>                  if you have some  suggestions could you please share
>         wth me?
>
>
>              I understand how you plan to do this, could I ask why you
>         need to dump
>              the written pages?
>
>
>                  --
>                  Thanks
>                  Dhyan
>
>                  On Tue, Jul 31, 2012 at 12:43 PM, bill4carson
>         <bill4carson at gmail.com <mailto:bill4carson at gmail.com>
>         <mailto:bill4carson at gmail.com <mailto:bill4carson at gmail.com>>
>         <mailto:bill4carson at gmail.com <mailto:bill4carson at gmail.com>
>         <mailto:bill4carson at gmail.com <mailto:bill4carson at gmail.com>>__>__>
>
>                  wrote:
>
>
>
>                       On 2012年07月30日 17:39, Dhyan wrote:
>
>                           Dear All,
>
>                             From linux(2.6.35) arm page table
>         architecture i can
>                  see we
>                           have one
>                           hardware page table and  there is
>         corresponding Linux
>                  page table
>                           Entry
>                           (L_PTE_*).The "Linux" PTE definitions are as
>         like below
>                  from
>                           arch/arm/include/asm/pgtable.______h.
>
>
>
>                           |#define L_PTE_PRESENT   (1<<  0)
>                           #define L_PTE_FILE      (1<<  1)
>                           #define L_PTE_YOUNG     (1<<  1)
>                           #define L_PTE_BUFFERABLE(1<<  2)
>                           #define L_PTE_CACHEABLE (1<<  3)
>                           #define L_PTE_USER      (1<<  4)
>                           #define L_PTE_WRITE     (1<<  5)
>                           #define L_PTE_EXEC      (1<<  6)
>                           #define L_PTE_DIRTY     (1<<  7)
>                           #define L_PTE_COHERENT  (1<<  9)
>                           #define L_PTE_SHARED    (1<<  10)
>                           |
>
>                           So is it possible to add one more #|define
>         L_PTE_DEBUG
>                  (1 <<
>                           11)| for my
>
>                           debugging purpose (basically to trap all the
>         write to
>                  that page
>                           and set
>                           this bit when write happens and clear it off
>         in another
>                  thread
>                           )? Or
>                           is there any limitation like we can use only
>         L_PTE till
>                  10th bit ?
>
>
>                       No such limitation on bit 11, so you can use define
>                  L_PTE_DEBUG (1
>         << 11)
>                       However I don't follow why you want to do so?
>
>
>                           So could you please help
>
>                           --
>
>                           Thanks & Regards
>
>                           Dhayn
>
>
>
>
>           _____________________________________________________
>                           Kernelnewbies mailing list
>                           Kernelnewbies at kernelnewbies.______org
>         <mailto:Kernelnewbies@
>         <mailto:Kernelnewbies@>__kernel__newbies.org
>         <http://kernelnewbies.org>
>         <mailto:Kernelnewbies at __kernelnewbies.org
>         <mailto:Kernelnewbies at kernelnewbies.org>>>
>         http://lists.kernelnewbies.______org/mailman/listinfo/______kernelnewbies
>
>         <http://lists.kernelnewbies.____org/mailman/listinfo/____kernelnewbies
>         <http://lists.kernelnewbies.__org/mailman/listinfo/__kernelnewbies
>         <http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies>>>
>
>
>
>                       --
>                       Love each day!
>
>                       --bill
>
>
>
>              --
>              Love each day!
>
>              --bill
>
>
>
>     --
>     Love each day!
>
>     --bill
>
>

-- 
Love each day!

--bill



More information about the Kernelnewbies mailing list