Re: [BUG 3.12.rc4] Oops: unable to handle kernel paging request during shutdown

[Knut Petersen <Knut_Petersen@t-online.de>]

On 15.10.2013 08:40, Ingo Molnar wrote:
> * Frederic Weisbecker <fweisbec@gmail.com> wrote:
>
>> I've been thinking that CONFIG_DEBUG_LIST could help. Unfortunately it's
>> good to spot list APIs misuse but, if Linus is right, the problem may be
>> that the list belongs to an object that has been freed, and I believe
>> that won't detect such a thing.
> Use-after free should be reliably detectable via CONFIG_DEBUG_PAGEALLOC=y.

Enabled.

Hmm ... I think i spotted a KConfig bug.  In mm/Kconfig.debug I read:

config DEBUG_PAGEALLOC
         bool "Debug page memory allocations"
         depends on DEBUG_KERNEL
         depends on !HIBERNATION || ARCH_SUPPORTS_DEBUG_PAGEALLOC && !PPC && !SPARC
         depends on !KMEMCHECK
         select PAGE_POISONING if !ARCH_SUPPORTS_DEBUG_PAGEALLOC
         select PAGE_GUARD if ARCH_SUPPORTS_DEBUG_PAGEALLOC
         ---help---
           Unmap pages from the kernel linear mapping after free_pages().
           This results in a large slowdown, but helps to find certain types
           of memory corruption.

           For architectures which don't enable ARCH_SUPPORTS_DEBUG_PAGEALLOC,
           fill the pages with poison patterns after free_pages() and verify
           the patterns before alloc_pages().  Additionally,
           this option cannot be enabled in combination with hibernation as
           that would result in incorrect warnings of memory corruption after
           a resume because free pages are not saved to the suspend image.


Either the description or the "depends" line that includes !HIBERNATION is wrong. Maybe

         depends on DEBUG_KERNEL
-        depends on !HIBERNATION || ARCH_SUPPORTS_DEBUG_PAGEALLOC && !PPC && !SPARC
+        depends on !HIBERNATION && ARCH_SUPPORTS_DEBUG_PAGEALLOC && !PPC && !SPARC
         depends on !KMEMCHECK

is correct, at least does not allow HIBERNATION and DEBUG_PAGEALLOC to be enabled simultaneously.

>
> A couple of years ago I wrote a list debugging beast that would catch
> use-after-free mishaps (sent it to lkml too IIRC), but it was a bit
> complex and I never found the time to nurse it upstream.
>
> Thanks,
>
> 	Ingo
>