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

[Knut Petersen]

On 15.10.2013 08:40, Ingo Molnar wrote:
> * Frederic Weisbecker <fweisbec@xxxxxxxxx> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/