linux-kernel - Re: [patch] suspend/resume self-test

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: <200802181216.25350.david-b@pacbell.net>
Date:	Mon, 18 Feb 2008 12:16:24 -0800
From:	David Brownell <david-b@...bell.net>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Pavel Machek <pavel@....cz>, rjw@...k.pl,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [patch] suspend/resume self-test

On Monday 18 February 2008, Ingo Molnar wrote:
> 
> * David Brownell <david-b@...bell.net> wrote:
> 
> > > >   - Includes a command line parameter, which needs work yet ... it
> > > >     currently turns this test off, but it should also let the target
> > > >     state be specified (and maybe even default to "no test").
> > 
> > I think "no test" should be the default; STR working sanely on x86 is 
> > unfortunately too much a surprise.  Someone more active in PM testing 
> > should update that.
> 
> All i'm asking for is to make the self-test easily accessible. Not for 
> it to blow up in the face of users who do not ask for it.

I'm all for that, but also I don't want to see it blow up regularly
in the face of people who just enable all the selftest options.  The
other tests have a much better expectation of working "by default".

> And, at least to me, there seems to be a rather apparent correlation 
> between "suspend/resume regressions caught as early as possible" and the 
> future, desired state of: "STR working sanely on x86" ;-)

Thing is, this will catch not just regressions ... but cases where
STR never worked in the first place.  Video problems, etc.  Also
various system startup races, as in the PCMCIA and MMC/SD/SDIO
cases I noted.

> You really seem to treat S2R suckiness as a fact of life, but it isnt.

Until it starts working on a given platform, it *IS* a fact of life.

Once it works, then it's fair to enter "no regressions" mode.  Despite
all the recent improvements, I think it's unwise to pretend that STR
works properly on most systems.

> Yes, it's a hard field for a number of reasons, but we could be doing _a 
> lot_ better. One of them would be this "notice s2r breakage when i 
> create or add the patch that breaks it" angle.

Right, and the best way to ensure that it's only *regressions* that
break things is to expect someone to have configured the kernel command
line appropriately (in grub or whatever).

Another way to achieve that is to include the test code based on one
config option, and change the test *mode* based on another one.  That
way a distro could include that in standard kernels with "no test" mode
as the default, but it would be easy to enable only for oneshot tests
or field troubleshooting ... while developers could turn on the more
dangerous "always test STR" (or standby, or hibernate) mode, if they
were helping to find and fix problems surfaced by such tests.

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