linux-kernel - Re: [RFC] get rid of CONFIG_DISABLE_CONSOLE

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]

Date:	Fri, 29 Jun 2007 14:36:41 +0200
From:	Stefan Seyfried <seife@...e.de>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Pavel Machek <pavel@....cz>, nigel@...el.suspend2.net,
	linux-kernel@...r.kernel.org, suspend-devel@...ts.sourceforge.net,
	Linus Torvalds <torvalds@...ux-foundation.org>, fseidel@...e.de
Subject: Re: [RFC] get rid of CONFIG_DISABLE_CONSOLE_SUSPEND

On Thu, Jun 28, 2007 at 09:12:44PM +0200, Rafael J. Wysocki wrote:
> On Thursday, 28 June 2007 19:25, Stefan Seyfried wrote:
> > 
> > However, we don't know which consoles are safe to stay alive during suspend.
> > Generally, defaulting to suspending them all is not a bad idea IMHO.
> > And IIRC it is plain luck if a serial console survives the suspend (or was
> > the serial code fixed recently?)
> 
> Well, I don't think so, but I'm not sure.
> 
> The VGA/fb console also should be off during suspend (not necessarily during
> hibernation, though).  IIRC, that's what caused Linus to introduce the
> suspending of consoles after all.
> 
> > So i do not care too much, but my / Frank's patch was shorter :-) and safer.
> 
> I'm not sure which way to go.  On the one hand, I agree that we should rather
> fix the consoles so that we know which one is suspend-safe and which is not
> and disable the unsafe ones, but on the other hand we are not there yet and it
> _sometimes_ is useful not to suspend a console even if we know that it will
> break things.

This is what my / Frank's patch was aimed at: give the user the ability to
(painlessly, without rebuilding the kernel) debug suspend problems. Keep the
default safe, like Linus likes it (consoles suspended), but give the user a
switch to make it unsafe (consoles not suspended) for the sake of debugging.

Of course, fixing up all console drivers is an option that i'd very much like
to see. It is however debatable if it is really worth the effort. If it works
with consoles suspended, the user does not care. If it doesn't, he turns on
debugging (knowing, or being told that this will break using netconsole).

I strongly oppose Pavel's approach to "declare all console drivers as
nonbroken except netconsole". Even if he has not seen any failures apart
from netconsole, in general i had the impression that suspending consoles
did help. At least suspend works on many more machines than half a year ago,
and i'd not be surprised if this was partly due to suspending the consoles.

Remember that wrt. suspend "i did not get a bugreport" very often just means
"people tried it, it did not work, but they expected that and just turned
 away". It does not mean "it just works for everyone".
-- 
Stefan Seyfried
QA / R&D Team Mobile Devices        |              "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg  | "Well, surrounding them's out." 

This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
-
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/