lkml.org 
[lkml]   [2008]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL] kmemcheck fixlets (for -tip)

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

> On Mon, Sep 29, 2008 at 10:55 AM, Ingo Molnar <mingo@elte.hu> wrote:
> > 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.
>
> Oops. Probably kmemcheck was not enabled (for all the right caches).
> Here's what may go wrong:
>
> 1. kmemcheck is in one-shot mode. Only one error is reported; after
> that, box will start returning to normal speed.

i'd have noticed that error.

> 2. SLUB debugging was enabled. kmemcheck will not track "debugged"
> caches, so I suggest turning SLUB off in kernel config, or by booting
> with "slub_debug=-". But I think that SLUB debug can be turned off in
> kernel config as well, which means that your randconfig testing will
> hit both cases eventually.

ok, slub debugging was indeed on. I'll re-test with that disabled.

> > [ 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.
> >
>
> You can read /proc/sys/kernel/kmemcheck. We also set a per-cache flag
> in slabs, so I think you can get some information from SLUB sysfs. But
> I agree -- it is not always easy to tell what kmemcheck is actually
> doing. Maybe some counters and stats would be appropriate.

ah, missed that flag.

> > 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.
>
> Uhm, not correct. We need a few more infos (like read size, shadow,
> etc.), also the stacktraces are saved, so the default stacktrace of
> WARN is useless. But we can certainly try to emulate it. What text
> should I insert in order for your scripts to pick it up?

a kernel log line beginning with:

INFO:
WARNING:
BUG:

would be noticed. (That pattern has to be at the beginning of the line.
Otherwise we'd match on things like 'DEBUG: ' - such printouts exist)

Ingo


\
 
 \ /
  Last update: 2008-09-29 11:29    [W:0.059 / U:0.808 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site