linux-kernel - Re: Slab BUG with DEBUG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sun, 8 Dec 2013 17:00:16 +0200 (EET)
From:	Meelis Roos <mroos@...ux.ee>
To:	Christoph Lameter <cl@...ux.com>
cc:	Pekka Enberg <penberg@...nel.org>, Matt Mackall <mpm@...enic.com>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	linux-mm@...ck.org, Joonsoo Kim <js1304@...il.com>,
	Peter Hurley <peter@...leysoftware.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	David Miller <davem@...emloft.net>, sparclinux@...r.kernel.org
Subject: Re: Slab BUG with DEBUG_* options

(Added 3 addresses to CC from my RED state exception thread since this 
is related)

> On Tue, 3 Dec 2013, Meelis Roos wrote:
> 
> > Tested it. seems to hang after switching to another console. Before
> > that, slabs are initialized successfully, I verified it with my previous
> > debug printk sprinkle patch. Many allocations are still off slab - is
> > that OK?
> 
> Yes that was the intend. Only exempt the small ones.
> 
> > console [tty0] enabled, bootconsole disabled
> 
> Looks like the bootstrap worked.

But the configuration should work fine with this console setup - with no 
slab debug options, it booted fine... I decided to do more tests.

In short, tests about 3.11-rc2-00058:

clean kernel: boots OK, RED state on shutdown (the actual problem I am 
chasing)

clean kernel, slab debug: mm crash

your second slab patch, slab debug: OK - this one shows that the RED 
state problem went away too which is good but strange

clean kernel, your second slab patch: OK - no RED state

Following another lead I had discovered that I can make the RED state 
problem go away if I switch tty ldata allocation from vmalloc to 
kmalloc. Tests with that:

ldata alloc change only, no slab debug: OK (works around RED state 
somehow)

ldata alloc change + slab debug: mm crash, can not test for RED state

ldata alloc change + your second slab patch + slab debug: hang on boot 
after
console [tty0] enabled, bootconsole disabled
(after that, I should see all the dmesg again on serial but I do not).

ldata alloc change + your second slab patch + no slab debug: OK

So, in short:

your slab patch 2 seems to cure both slab debug startup crash and the 
RED state problem in this specific version of the kernel. However, it is 
still mystery to me why tty ldata alloc change vmalloc->kmalloc would 
break but that may to be in the serial field - will do more tests with 
this patch applied and newer kernels.

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