Messages in this thread | | | Date | Mon, 29 Sep 2008 10:55:12 +0200 | From | Ingo Molnar <> | Subject | Re: [GIT PULL] kmemcheck fixlets (for -tip) |
| |
* Vegard Nossum <vegard.nossum@gmail.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
| |