linux-kernel - Re: [GIT PULL] kmemcheck fixlets (for -tip)

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:	Mon, 29 Sep 2008 10:55:12 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Vegard Nossum <vegard.nossum@...il.com>
Cc:	Pekka Enberg <penberg@...helsinki.fi>, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] kmemcheck fixlets (for -tip)

* Vegard Nossum <vegard.nossum@...il.com> wrote:

> Hi Ingo,
> 
> Here is the fixlets branch, including bitfields API. I think it would 
> be very nice if you could make this a *separate* branch in -tip, say 
> kmemcheck-fixlets or so, as it may touch any part of the kernel and 
> doesn't carry the acks of those maintainers.
> 
> With these patches, you should be able to include kmemcheck in 
> auto-testing again. At least it works for me :-)

FYI, i've reactivated kmemcheck on one of the -tip auto-test boxes 
earlier today and it's looking good so far - for example a 32-bit 
allyesconfig-ish config booted in just fine with kmemcheck enabled. 
Also, the box is very usable interactively - while previous one could 
always tell whether there's kmemcheck active.

[ only one CPU is active, but we knew that. We've still got this 
  test-commit:

     21d01a4: x86: add functions for duplicating page tables

  it's not in tip/master but we still have it around. ]

btw., is there any easy way to tell from within a script what the 
current status of kmemcheck is? In particular, whether it's running. 
Normally i have this in the syslog:

 [    0.448022] kmemcheck: "Bugs, beware!"
 [    0.452002] kmemcheck: Limiting number of CPUs to 1.

but this time the log was too large so this bit was snipped out and i 
was unsure about it - needed a second bootup with a larger buffer to 
make sure. With lockdep we've got the 'debug_locks' /proc/lockdep_stats.

also, all kmemcheck warnings follow the usual WARN_ON() format, so that 
automated tests can pick it up, correct? -tip testing does so many 
bootups that there's no chance to notice non-system-crashing bugs and 
printouts but via automated means.

	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/