RE: accessed/dirty bit handler tuning

From: Chen, Kenneth W <kenneth.w.chen_at_intel.com>
Date: 2006-03-30 09:59:21
Zoltan Menyhart wrote on Wednesday, March 29, 2006 9:02 AM
> Can you please tell me why are the pud - pmd pointers are re-checked
> in "vhpt_miss" ?

This code has been there for over five years, and was written by a
prominent ia64 pioneer. I trusted it with my whole heart that it is
there for a good reason.


> As far as I know, pud, pmd, pte pages can go away only via:
> 
> 	free_pgtables()
> 		free_pgd_range()
> 			free_pud_range()
> 				free_pmd_range()
> 					free_pte_range()
> 
> If a 0xa000... stuff goes away => BUG.
> For the user mode pages:
> 
> "free_pgtables()" is called only from:
> 
> - "exit_mmap()": we simply cannot have the chance to have a vhpt miss
> - "unmap_region()" calls "unmap_vmas()" before "free_pgtables()":
>    again, we cannot fault in that region
> 
> Have I missed something?

OK, let's see what happens without re-read pud/pmd:

cpu0                            cpu1                  cpu2
Vhpt miss:
  walk page table
                                free_pgtables
                                ptc.g fault address
                                ptc.g hash address
                                                      pud_alloc/pmd_alloc
                                                      new page instantiation
  itc.d faulting address
  itc.d hash address
  read pte
  kill tlb for fault addr
  rfi

Touch fault addr
Walker install the tlb
with staled vhpt tlb
-> using someone else's page
 -> data corruption
   -> poor kernel engineer
      scratch his head with
      straight 7 days of debug
      with no clue what the
      hack is going on ....

It's a far fetched scenario, but ....

I suppose we can close the race with killing hash address tlb along with
the faulting address tlb.

- Ken
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Thu Mar 30 10:00:05 2006

This archive was generated by hypermail 2.1.8 : 2006-03-30 10:01:15 EST