Wie bekomme ich Informationen aus einem Kernel-Platten-Korruptionsbericht?

Question

ich das Debuggen ein Dateisystem Korruption (manchmal sehe ich Symlinks auf "" nach Berg zeigt) und ich konnte die üblichen Config in menuconfig (EXPERT, KALLSYMS, DEBUG_KERNEL, DEBUG_VM, DEBUG_SLAB, DEBUG_LIST, DEBUG_MUTEXES, CC_STACKPROTECTOR, etc.), um zu versuchen um Infos zu bekommen. Dies ist auf einem 3.18-stabilen Kernel.

Mit dem Debug-Kernel ich manchmal Berichte wie diese sehen, wenn rootfs Montage, die im Zusammenhang aussehen:

Slab corruption (Tainted: P W O): kmalloc-32 start=ac526c20, len=32 
000: 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b .kkkkkkkkkkkkkkk 
Prev obj: start=ac526c00, len=32 
000: 00 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a .ZZZZZZZZZZZZZZZ 
010: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a a5 ZZZZZZZZZZZZZZZ. 
Next obj: start=ac526c40, len=32 
000: 00 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a .ZZZZZZZZZZZZZZZ 
010: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a a5 ZZZZZZZZZZZZZZZ. 

Ich versuche, herauszufinden, was Code zugewiesen oder befreit den Speicher (in den Cache zurück) oder sowas ähnliches.

Ich habe getestet mit DEBUG_PAGEALLOC = y und = n aber ich sehe nicht "Last user" info (dh der Stapel für das kmalloc) in dmesg, die nach slab.c [1] sollte gedruckt werden, wenn der Speicher Block-Header hat die SLAB_STORE_USER Flagge.

Meine Frage ist, wie bekomme ich die Alloc-Stacks im Korruptionsbericht angezeigt werden?

EDIT: Laut slub.txt [2], ist dies möglicherweise nur mit SLUB möglich.

[1] http://elixir.free-electrons.com/linux/v3.18.80/source/mm/slab.c#L1735

[2] https://www.kernel.org/doc/Documentation/vm/slub.txt

Answer 1

meine eigene Frage zu beantworten. SLUB gibt dir eine Backtrace und Redzone Info. Ich aktivierte SLUB, SLUB_DEBUG, CONFIG_SLUB_DEBUG_ON.

BUG kmalloc-32 (Tainted: P O): Redzone overwritten 
INFO: Allocated in custom_read+0x2c/0x9c age=1 cpu=1 pid=2856 
    custom_read+0x2c/0x9c 
    vfs_read+0x84/0xec 
    SyS_read+0x4c/0x9c 
    ret_fast_syscall+0x0/0x4c 
INFO: Freed in link_path_walk+0x594/0x770 age=1 cpu=1 pid=2856 
    path_lookupat+0x20/0x674 
    filename_lookup.isra.10+0x20/0x5c 
    user_path_at_empty+0x60/0x9c 
... 

Es war ein Off-by-one, die eine \ 0 auf das nächste Objekt gesetzt, die eine inode-> I_NAME war.