Memory management bug

I think I spotted a problem in the memory management of some (all?) architectures in 2.4.0-test10. At the moment I am fighting with the 64bit backend for the new S/390 machines. I experienced infinite loops in do_check_pgt_cache because pgtable_cache_size indicated that a lot of pages are in the quicklists but the pgd/pmd/pte quicklists have been empty (NULL pointers). After some trickery with some special hardware feature (storage keys) I found out that empty_bad_pmd_table and empty_bad_pte_table have been put to the page table quicklists multiple(!) times. It is already a bug that these two arrays are inserted into the quicklist at all but the second insertation destroys the quicklists. I solved this problem by inserting checks for the special entries in the free_xxx_fast routines, here is a sample for the i386 free_pte_fast:

diff -u -r1.5 pgalloc.h
@@ -80,8 +80,11 @@
        return (pte_t *)ret;
 }
 
+extern pte_t empty_bad_pte_table[];
 extern __inline__ void free_pte_fast(pte_t *pte)
 {
+       if (pte == empty_bad_pte_table)
+               return;
        *(unsigned long *)pte = (unsigned long) pte_quicklist;
        pte_quicklist = (unsigned long *) pte;
        pgtable_cache_size++;

I still get the "__alloc_pages: 2-order allocation failed." error messages but at least the machine doesn't go into infinite loops anymore. Could someone with more experience with the other architectures verify that my observation is true?

blue skies,
Martin

Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH Schönaicherstr. 220, D-71032 Böblingen, Telefon: 49 - (0)7031 - 16-2247
E-Mail: [email protected]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

In article <[email protected]>,

This is definitely bad, and means that something else really bad is going on.

In fact, I have this fairly strong suspicion that we should just get rid of the "bad" page tables altogether, and make the stuff that now uses them BUG() instead.

The whole concept of "bad" page tables comes from very early on in Linux, when the way the page fault handler worked was that if it ran out of memory or something else really bad happened, it would insert a dummy page table entry that was guaranteed to let the CPU continue. That way the page fault handler was always "successful" from a hardware standpoint, even if it ended up trying to kill the process.

This used to be required simply because a page fault in kernel space originally needed to let the process unwind sanely and cleanly.

These days, the requirement that page faults always "succeed" is long long gone. The exception handling mechanism handles the cases where we validly can take a page fault, and in other cases we will just kill the process outright. As such, the bad page tables should no longer be needed, and are apparently just hiding some nasty bugs.

What happens if you just replace all places that would use a bad page table with a BUG()? (Ie do _not_ add the bug to the place where you added the test: by that time it's too late. I'm talking about the places where the bad page tables are used, like in the error cases of "get_pte_kernel_slow()" etc.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/