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: <20080530105948.GA12236@elte.hu>
Date:	Fri, 30 May 2008 12:59:48 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	David Brownell <david-b@...bell.net>, linux-kernel@...r.kernel.org,
	linux-pm@...ts.linux-foundation.org, pavel@...e.cz
Subject: Re: [patch 2.6.26-rc4-git] PM: boot time suspend selftest


* Andrew Morton <akpm@...ux-foundation.org> wrote:

> > +	WARN_ON_ONCE(msec > (TEST_SUSPEND_SECONDS * 1000));
> 
> We should have a comment here explaining what we're warning about.  
> Why would it take more that five seconds?

i asked for that because we had regressions in the past in the form of 
"it takes one minute to resume".

> Better might be to just add a nice printk - I don't think we need the 
> stack trace here.

please keep the warn-on so that it can be detected automatically. Adding 
yet another printk just complicates the automated answer to the "is this 
kernel that just booted up fine or not" question.

In fact i'd love to have the analogue to /proc/lockdep_debug's 
"debug_locks: 0" output. I.e. the kernel should know it via one central 
flag whether any bugs that need human review have been detected so far. 

Say /proc/sys/kernel/kernel_is_buggy. This value could even be 
multi-level: a WARN_ON() increases it by +1, a kernel crash increases it 
by +1000. ( That way i could run overnight tests that will only stop on 
a kernel_is_buggy >= 1000 condition, while it could ignore simpler 
WARN_ON()s. )

	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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ