From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752971AbYI2J0L (ORCPT ); Mon, 29 Sep 2008 05:26:11 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754159AbYI2JZy (ORCPT ); Mon, 29 Sep 2008 05:25:54 -0400 Received: from mx3.mail.elte.hu ([157.181.1.138]:51537 "EHLO mx3.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754114AbYI2JZx (ORCPT ); Mon, 29 Sep 2008 05:25:53 -0400 Date: Mon, 29 Sep 2008 11:25:46 +0200 From: Ingo Molnar To: Vegard Nossum Cc: Pekka Enberg , linux-kernel@vger.kernel.org Subject: Re: [GIT PULL] kmemcheck fixlets (for -tip) Message-ID: <20080929092546.GB7735@elte.hu> References: <20080928180652.GA8500@localhost.localdomain> <20080929085512.GA2190@elte.hu> <19f34abd0809290213m54a2c485p5917fcd46747ad6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19f34abd0809290213m54a2c485p5917fcd46747ad6@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-ELTE-VirusStatus: clean X-ELTE-SpamScore: -1.5 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-1.5 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.2.3 -1.5 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Vegard Nossum wrote: > On Mon, Sep 29, 2008 at 10:55 AM, Ingo Molnar 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