2.6.27-stable review patch. If anyone has any objections, please let us know. ------------------ From: Peter Zijlstra commit 42ef73fe134732b2e91c0326df5fd568da17c4b2 upstream. On -rt we were seeing spurious bad page states like: Bad page state in process 'firefox' page:c1bc2380 flags:0x40000000 mapping:c1bc2390 mapcount:0 count:0 Trying to fix it up, but a reboot is needed Backtrace: Pid: 503, comm: firefox Not tainted 2.6.26.8-rt13 #3 [] ? printk+0x14/0x19 [] bad_page+0x4e/0x79 [] free_hot_cold_page+0x5b/0x1d3 [] free_hot_page+0xf/0x11 [] __free_pages+0x20/0x2b [] __pte_alloc+0x87/0x91 [] handle_mm_fault+0xe4/0x733 [] ? rt_mutex_down_read_trylock+0x57/0x63 [] ? rt_mutex_down_read_trylock+0x57/0x63 [] do_page_fault+0x36f/0x88a This is the case where a concurrent fault already installed the PTE and we get to free the newly allocated one. This is due to pgtable_page_ctor() doing the spin_lock_init(&page->ptl) which is overlaid with the {private, mapping} struct. union { struct { unsigned long private; struct address_space *mapping; }; spinlock_t ptl; struct kmem_cache *slab; struct page *first_page; }; Normally the spinlock is small enough to not stomp on page->mapping, but PREEMPT_RT=y has huge 'spin'locks. But lockdep kernels should also be able to trigger this splat, as the lock tracking code grows the spinlock to cover page->mapping. The obvious fix is calling pgtable_page_dtor() like the regular pte free path __pte_free_tlb() does. It seems all architectures except x86 and nm10300 already do this, and nm10300 doesn't seem to use pgtable_page_ctor(), which suggests it doesn't do SMP or simply doesnt do MMU at all or something. Signed-off-by: Peter Zijlstra Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman --- include/asm-x86/pgalloc.h | 1 + 1 file changed, 1 insertion(+) --- a/include/asm-x86/pgalloc.h +++ b/include/asm-x86/pgalloc.h @@ -42,6 +42,7 @@ static inline void pte_free_kernel(struc static inline void pte_free(struct mm_struct *mm, struct page *pte) { + pgtable_page_dtor(pte); __free_page(pte); } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/