linux-kernel - Re: [bug] WARNING: at drivers/char/tty_io.c:1266 tty

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090616102418.GC28204@elte.hu>
Date:	Tue, 16 Jun 2009 12:24:18 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	linux-kernel@...r.kernel.org,
	Pekka Enberg <penberg@...helsinki.fi>,
	Vegard Nossum <vegard.nossum@...il.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [bug] WARNING: at drivers/char/tty_io.c:1266
	tty_open+0x1ea/0x388()

* Alan Cox <alan@...rguk.ukuu.org.uk> wrote:

> > I have applied your patch from yesterday (attached further below for 
> > reference) and the SLAB corruption has not triggered - instead i'm 
> > now getting this warning, after 96 reboots
> 
> That one is interesting btw - however its not a new bug. The 
> WARN_ON() was added in the new patches to catch cases where the 
> tty open/close locking was broken and see if all the ldisc related 
> ones were nailed.
> 
> Apparently on a very SMP box they are not. It's not however a new 
> bug - just the result of checking for the problem.
> 
> +        WARN_ON(!test_bit(TTY_LDISC, &tty->flags));
> 
> 
> ..
> 
> which means that someone cleared the ldisc behind our back despite 
> us holding tty_mutex. That would suggest a hangup/reopen race 
> which shouldn't be too hard to find.
> 
> Dunno what you feed your SMP box but its very useful 8)

it's plain old-fashioned brute force plus a randconfig search: if a 
race is possible it will trigger eventually here, given the right 
hardware (i use a number of different systems), given the right 
user-space (i use heterogenous installations), given the right 
compiler/binutils (that too is heterogenous) and the right timing 
and kernel feature combo via a huge, 2^1000 randconfig space.

Plus this system is an old P4 HyperThreading dual-socket system: 
pretty much the only thing HyperThreading is good for on that box is 
finding SMP races: that CPU can (and will) yield between 
hyperthreads on arbitrary instruction boundaries - opening up races 
wide open.

In fact we had races in the past that would only trigger on that 
box, ever. (note that this warning did trigger on another box as 
well - after 350+ bootups ...) And we thought P4-HT is pure crap ;-)

	Ingo
--
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/