linux-kernel - Re: echo mem > /sys/power/state

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: <20080118121803.GF11044@elte.hu>
Date:	Fri, 18 Jan 2008 13:18:03 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>, Zan Lynx <zlynx@....org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Len Brown <lenb@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: echo mem > /sys/power/state

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

> > (it doesnt matter if graphics does not resume fine - at least for my 
> > tests)
> > 
> > kprobes had similar problems and it now has a few simple smoke-tests 
> > - which i just saw trigger on a patch that i did not notice would 
> > break kprobes. I think this should be done for all functionality 
> > that is not regularly triggered by a normal distro bootup (and which 
> > is easy to overlook in testing).
> 
> Seeing as we're so lame about being able to distribute userspace 
> stuff: create a shell script in /proc/rc.kernel and start teaching 
> initscripts to run it.  Then we can modify it at will.

would be fine to me. The problem isnt just distribution and the tests 
getting out of sync with the kernel (and its capabilities enabled in the 
.config, etc.), the other problem is unintrusive testing: i for example 
use unmodified images of various distributions, with only a new bzImage 
plopped in. That is an intentionally minimal impact test vector, any 
userspace side changes are discouraged. And that's how many people test 
new kernels, they just plop it in. The moment we require any userlevel 
changes, the testing barrier increases significantly.

[ and a Friday rant: that's why the objection against my 
  make-relatime-actually-useful-to-people patch is so stupid, 
  shortsighted, self-defeating and misplaced. The "Dont put policy into 
  the kernel, use a new mount option and update your /etc/fstab" 
  stupidity that people have been repeating for 10 years without 
  thinking about it is a move that scares away 90% of our testers and
  99% of the distros. See:

    http://people.redhat.com/mingo/relatime-patches/improve-relatime.patch

  Trivial improvement, it's 6 months and still not upstream. We are just 
  so good at shooting in our feet by creating artificial barriers and 
  making it as hard as possible for people to actually use our kernel 
  features ;-) ]

	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/