On Fri, Feb 25, 2011 at 07:04:43PM +0100, Peter Zijlstra wrote: > I'm not quite sure why you chose to add range tracking on > pte_free_tlb(), the only affected code path seems to be unmap_region() > where you'll use a flush_tlb_range(), but its buggy, the pte_free_tlb() > range is much larger than 1 page, and if you do it there you also need > it for all the other p??_free_tlb() functions. My reasoning is to do with the way the LPAE stuff works. For the explaination below, I'm going to assume a 2 level page table system for simplicity. The first thing to realise is that if we have L2 entries, then we'll have unmapped them first using the usual tlb shootdown interfaces. However, when we're freeing the page tables themselves, we should already have removed the L2 entries, so all we have are the L1 entries. In most 'normal' processors, these aren't cached in any way. Howver, with LPAE, these are cached. I'm told that any TLB flush for an address which is covered by the L1 entry will cause that cached entry to be invalidated. So really this is about getting rid of cached L1 entries, and not the usual TLB lookaside entries that you'd come to expect. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>