Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1764770AbXEYRjW (ORCPT ); Fri, 25 May 2007 13:39:22 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1763458AbXEYRix (ORCPT ); Fri, 25 May 2007 13:38:53 -0400 Received: from smtp1.linux-foundation.org ([207.189.120.13]:49649 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1764864AbXEYRiv (ORCPT ); Fri, 25 May 2007 13:38:51 -0400 Date: Fri, 25 May 2007 10:37:14 -0700 From: Andrew Morton To: Linus Torvalds Cc: Alan Cox , Chris Newport , Ingo Molnar , Christoph Lameter , Michal Piotrowski , LKML , "Cherwin R. Nooitmeer" , linux-pcmcia@lists.infradead.org, Robert de Rooy , Alan Cox , Tejun Heo , sparclinux@vger.kernel.org, David Miller , Mikael Pettersson , linux1394-devel@lists.sourceforge.net, Stefan Richter , Kristian H?gsberg , linux-pm@lists.linux-foundation.org, "Rafael J. Wysocki" , Pavel Machek , Marcus Better , Andrey Borzenkov , linux-usb-devel@lists.sourceforge.net, Greg Kroah-Hartman Subject: Re: [2/3] 2.6.22-rc2: known regressions v2 Message-Id: <20070525103714.092ad631.akpm@linux-foundation.org> In-Reply-To: References: <46558708.2040803@googlemail.com> <46559B54.80106@googlemail.com> <20070524193740.GA6787@elte.hu> <20070525101105.GA9268@elte.hu> <4656CE39.8050800@netunix.com> <20070525180304.2cc4dae0@the-village.bc.nu> X-Mailer: Sylpheed 2.4.1 (GTK+ 2.8.17; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2647 Lines: 65 On Fri, 25 May 2007 10:19:52 -0700 (PDT) Linus Torvalds wrote: > > > On Fri, 25 May 2007, Alan Cox wrote: > > > > There is an additional factor - dumps contain data which variously is - > > copyright third parties, protected by privacy laws, just personally > > private, security sensitive (eg browser history) and so on. > > Yes. We're uninterested in pagecache and user memory and they should be omitted from the image (making it enormously smaller too). That leaves security keys and perhaps filenames, and these could probably be addressed. > I'm sure we've had one or two crashdumps over the years that have actually > clarified a bug. > > But I seriously doubt it is more than a handful. We've had a few more than that, but all the ones I recall actually came from the kdump developers who were hitting other bugs and who just happened to know how to drive the thing. > > Diskdump (and even more so netdump) are useful in the hands of a > > developer crashing their own box just like kgdb, but not in the the > > normal and rational end user response of "its broken, hit reset" > > Amen, brother. > > Even for developers, I suspect a _lot_ of people end up doing "ok, let's > bisect this" or some other method to narrow it down to a specific case, > and then staring at the source code once they get to that point. > > At least I hope so. Even in user space, you should generally use gdb to > get a traceback and perhaps variable information, and then go look at the > source code. > > Yes, dumps can (in theory) be useful for one-off issues, but I doubt many > people have ever been able to get anything much more out of them than from > a kernel "oops" message. > > For developers, I can heartily recommend the firewire-based remote debug > facilities that the PowerPC people use. I've used it once or twice, and it > is fairly simple and much better than a full dump (adn it works even when > the CPU is totally locked up, which is the best reason for using it). > > But 99% of the time, the problem doesn't happen on a developer machine, > and even if it does, 90% of the time you really just want the traceback > and register info that you get out of an oops. > Often we don't even get that: "I was in X and it didn't hit the logs". You can learn a hell of a lot by really carefully picking through kernel memory with gdb. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/