linux-kernel - Re: [RFC] sleepy linux

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:	Tue, 8 Jan 2008 17:37:44 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Pavel Machek <pavel@....cz>
Cc:	kernel list <linux-kernel@...r.kernel.org>,
	Linux-pm mailing list <linux-pm@...ts.osdl.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: [RFC] sleepy linux


* Pavel Machek <pavel@....cz> wrote:

> > a quick feature request: could you please make the wake-on-RTC 
> > capability generic and add a CONFIG_DEBUG_SUSPEND_ON_RAM=y config 
> > option (disabled by default) that does a short 1-second 
> > suspend-to-RAM sequence upon bootup? That way we could test s2ram 
> > automatically (which is a MUCH needed feature for automated 
> > regression testing and automatic bisection). In addition, some sort 
> > of 'suspend for N seconds' /sys or /dev/rtc capability would be nice 
> > as well.
> 
> Hmm, are you sure it is good idea to do this from kernel? I guess this 
> is better done from script...

i have this low-prio effort to make all self-checks automatically 
available via 'make randconfig' as well, for all features that have no 
natural exposure during normal bootup. So far we've got rcutorture, 
kprobes-check, locking/lockdep-self-test and a handful of others. 
External scripts tend to go out of sync and LTP takes way too much time 
to finish.

> > btw., how far are you from having a working prototype?
> 
> SCSI/SATA issues stop me just now, but even if I get that to work, it 
> will be extremely disgusting hack... and it is unclear how to do it 
> nicely :-(.

as long as the sleep periods are within say 10-20 seconds, and our s2ram 
cycle is fast and optimal enough, we could do this with networking 
enabled too, without dropping/stalling TCP connections left and right.

(Perhaps if we could notify routers that they should batch packets for N 
seconds and we could turn off PHY during that time, it would be even 
nicer - is there any such router extension in existence?)

but if it's nothing else but a s2ram debug/stress utility, that alone 
would be great too :-)

	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/