On Wed, Apr 23, 2008 at 6:53 PM, Linus Torvalds<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:> Padding 0xffff8100201a0000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk> ....> Padding 0xffff8100201a71a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkkҐ> Padding 0xffff8100201a71b0: cc cc cc cc cc cc cc cc 00 00 1a 20 00 81 ff ff ММММММММ......яя> Padding 0xffff8100201a71c0: cd 70 17 a0 ff ff ff ff 00 00 00 00 73 05 00 00 Нp..яяяя....s...> Padding 0xffff8100201a71d0: b6 54 58 00 01 00 00 00 d5 71 26 81 ff ff ff ff ¶TX.....Хq&.яяяя>> Padding 0xffff8100201a71e0: 00 00 00 00 7c 05 00 00 97 54 58 00 01 00 00 00 ....|....TX.....>> which in turn is interesting because it very much looks like SLUB> re-used a page for something else (the values that things got> overwritten by are largely SLUB's own poison bytes: 6b is POISON_FREE,> the a5 at the end of the list of 6b's is POISON_END, while cc is> SLUB_RED_ACTIVE).>> To me, that pattern looks like an order-3 allocation (correct: that's what> kmalloc-4096 is supposed to be using!) got released, and the stuff at the> end (with slub debugging, there's only room for 7 4096-byte allocations> there, so 71b0 is past the end) in that SLUB debug info.>> The first word of that busy allocation is ffff8100201a0000, which is also> the base pointer to the whole order-3 page ("Free pointer"), followed by> the SLAB tracking data.
Is the POISON_FREE ("6b") region really contiguous Zdenek? The problemhere is that the object looks to be 29104 bytes that is subject tokmalloc_large() which by-passes SLUB poisoning completely.
Pekka��.n��������+%������w��{.n�����{�����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
