arm L_PTE_XXX entry addition for Debugging purpose

Dhyan linuxdhyan at gmail.com
Thu Aug 2 05:03:25 EDT 2012


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.

--
Thanks
Dhyan

On Thu, Aug 2, 2012 at 2:12 PM, bill4carson <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>**> 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>**
>> >__>
>>
>>         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 at __kernel**newbies.org<http://kernelnewbies.org>
>>         <mailto:Kernelnewbies@**kernelnewbies.org<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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120802/572c9b86/attachment-0001.html 


More information about the Kernelnewbies mailing list