linux-kernel - Re: WARNING at: drivers/char/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: <20090803103746.264c3acf@lxorguk.ukuu.org.uk>
Date:	Mon, 3 Aug 2009 10:37:46 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
	Sergey Senozhatsky <sergey.senozhatsky@...l.by>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Greg KH <greg@...ah.com>
Subject: Re: WARNING at: drivers/char/tty_ldisc.c

> I wonder if the hack is strictly necessary, or could perhaps at least be 
> moved down a bit. The comment around that area seems to imply there were 
> other issues ("will cause tty->count and state->count to go out of sync"), 
> and that whole tty->count thing is some seriously old code, and the tty 
> layer has changed a lot since 1992.

They will go out of sync for some hardware. Other stuff will get shut
down. 

> So I do get the feeling that it may be just old code that simply nobody 
> has dared remove - it may have made more sense back when then it does 
> now, and has just been carried around.

Alas not: eg

->hangup
uart_hangup
uart_flush_buffer
uart_shutdown
	drops carrier and dtr
	shuts down the port
	frees the IRQ handler
	kills off the transmit buffer & tasklet

whether the resulting mess happens to still work with printk rather
depends upon what ->ops->shutdown does. Even on x86 that will drop a
remote console if the carrier is being used so you won't see printk
messages after that point as you got a modem hangup.

A re-open as a device isn't a problem (we cleared ASYNCB_INITIALIZED) -
its the printk side that kills you, and someone is going to have to read
all the embedded device consoles as they are both the most likely to
break and most used 8(

> If it actually were to cause problems with the tty->count thing, I think 
> Sergey should have seen it thanks to us still doing that old 
> CHECK_TTY_COUNT thing.

Only if you get things like crossing open/close and the port bumps the
counts internally for console uses (where hangup will then set it to zero
and break). USB still does that but the last patches to USB also pushed
hangup/console awareness into USB a bit so it knows at the hardware level
not to shut down the console device entirely.

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