Question about free_pgd_slow ?

Question about free_pgd_slow ?

[rocky]

Hi,all

free_pgd_slow in arch/arm/mm/pgd.c  free the 4 pages at pgd level,
while could I ask a question about why free the page by pointed by pgd index 0 ?

cannot figure it out, any tips ?

thanks


rocky




       

Question about free_pgd_slow ?

[Rabin Vincent]

On Fri, Feb 25, 2011 at 09:05, rocky <bill_carson@126.com> wrote:
> free_pgd_slow in arch/arm/mm/pgd.c ?free the 4 pages at pgd level,l
> while could I ask a question about why free the page by pointed by pgd
> index 0 ?

Besides the 16k for the pgd, it frees the second level* page table
referenced at index 0 of the pgd.

(* - of course it frees pud+pmd+pte, but on current ARM this folds down
to just the second level page table.)

On ARM, FIRST_USER_ADDRESS is set to PAGE_SIZE because the vectors may
need to be placed at 0x0.  Since the tables for that translation have to
always be active, functions like exit_mmap() will not free the 0th
secondary level page table (see the calls to free_pgtables() there).  So
we free it here when we're freeing the pgd.

Question about free_pgd_slow ?

[rocky]

At 2011-03-02 23:52:03?"Rabin Vincent" <rabin@rab.in> wrote:>On Fri, Feb 25, 2011 at 09:05, rocky <bill_carson@126.com> wrote:>> free_pgd_slow in arch/arm/mm/pgd.c  free the 4 pages at pgd level,l>> while could I ask a question about why free the page by pointed by pgd>> index 0 ?>>Besides the 16k for the pgd, it frees the second level* page table>referenced at index 0 of the pgd.>>(* - of course it frees pud+pmd+pte, but on current ARM this folds down>to just the second level page table.)>>On ARM, FIRST_USER_ADDRESS is set to PAGE_SIZE because the vectors may>need to be placed at 0x0.  Since the tables for that translation have to>always be active, functions like exit_mmap() will not free the 0th>secondary level page table (see the calls to free_pgtables() there).  So>we free it here when we're freeing the pgd.
Thanks Rabin
I dig the code more deeper,
exit_mmap called free_pgtables by setting floor with FIRST_USER_ADDRESS, 
then in free_pgd_range , vma->start first aligned with PMD_MASK before compared with floor, 
PMD_MASK for arm is 2M aligned ,so that means 0~0x200000 virtual address mapping is free in
free_pgd_slow.

But I still dont get it, 
why is that  low vector mapping must always be active even though the task is going to exit?

rocky



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110305/374de67a/attachment-0001.html>

Question about free_pgd_slow ?

[Rabin Vincent]

2011/3/5 rocky <bill_carson@126.com>:
> But I still dont get it, why is that  low vector mapping must always
> be active even though the task is going to exit?

exit_mmap() is called by the exiting task.  In this case, the page table
that free_pgtables() operates on is the page table which is currently
in use.  Consider what would happen if we remove the vector mapping here
and an interrupt hits immediately after -- the cpu will (recursively)
fault while trying to find the vector page mapping.

pgd_free() on the other hand is safe because it's called when we've
switched away from this mm, and the page table is no longer in use
(mm->mm_count == 0).

Have a look at exit_mm(), which increases the mm_count before calling
mm_put(), and finish_task_switch(), which does the mmdrop().

Question about free_pgd_slow ?

[rocky]

At 2011-03-07 22:44:58?"Rabin Vincent" <rabin@rab.in> wrote: >2011/3/5 rocky <bill_carson@126.com>: >pgd_free() on the other hand is safe because it's called when we've >switched away from this mm, and the page table is no longer in use >(mm->mm_count == 0). > >Have a look at exit_mm(), which increases the mm_count before calling >mm_put(), and finish_task_switch(), which does the mmdrop().

crystal clear:)
your explanation DOES make sense

I can say when mm->mm_count ==0 , current_thread_info is not the thread info corresponding with mm used in mmdrop()

currently I am working on hugetlb for ARM
I put huge page table in thread_info when calling pgd_alloc
and wants to free it in pgd_free which is doomed to fail.
now I move those cookies into mm_struct , definitely not right place.
but I cannot find a desired place!

Thanks Rabin

rocky













-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110309/41fbdff1/attachment.html>