linux-kernel - Re: [PATCH] 8250: Don't restore NS16550 mode when console suspend is disabled

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: <20090513163507.556c3832@lxorguk.ukuu.org.uk>
Date:	Wed, 13 May 2009 16:35:07 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	dsaxena@...xity.net, linux-serial@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] 8250: Don't restore NS16550 mode when console suspend
 is disabled

> So we _could_ just save the mode, but that isn't really what this patch is 
> all about. The patch in question is about a total hack to avoid touching a 
> piece of hardware that we simply don't consider normal.

The driver knows and assumes the chip is stuck back into the right
configuration. Things like ttyS0 shared as console and tty won't work
right if we simply pray the configuration comes back sane. It may well do
on OLPC but on a standard generic PC we can't bet on it. If the user has
a high console speed set this patch will do the wrong thing.

No suspend console meaning "I'd like to debug suspend/resume" is only
useful if we actually put the bits back into a sane state coming out of
suspend to ram (and in some cases suspend to disk)

Deepak's original patch from 2008 is actually much better. He puts the
chip back in the right hardware configuration for the speed. He doesn't
randomly regress other platforms and configurations and he does it by
calling the standard methods in the driver to do the job.

http://dev.laptop.org/~dsaxena/patches/console_suspend_old.patch

It also has another advantage - it fixes the behaviour for almost
everything in drivers/serial not just a specific uart. Technically he
should take tty->termios_mutex before state->mutex in that code path as
the upstream code has changed but in every other respect its the proper
solution.

So can we apply Deepak's original correct 2008 patch instead please ?

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/