linux-kernel - Re: [2/3] 2.6.22-rc2: known regressions v2

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]

Message-ID: <20070528034640.GA6367@in.ibm.com>
Date:	Mon, 28 May 2007 09:16:40 +0530
From:	Vivek Goyal <vgoyal@...ibm.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Chris Newport <crn@...unix.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Christoph Lameter <clameter@....com>,
	Michal Piotrowski <michal.k.k.piotrowski@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"Cherwin R. Nooitmeer" <cherwin@...il.com>,
	linux-pcmcia@...ts.infradead.org,
	Robert de Rooy <robert.de.rooy@...il.com>,
	Alan Cox <alan@...hat.com>, Tejun Heo <htejun@...il.com>,
	sparclinux@...r.kernel.org, David Miller <davem@...emloft.net>,
	Mikael Pettersson <mikpe@...uu.se>,
	linux1394-devel@...ts.sourceforge.net,
	Stefan Richter <stefanr@...6.in-berlin.de>,
	Kristian H?gsberg <krh@...planet.net>,
	linux-pm@...ts.linux-foundation.org,
	"Rafael J. Wysocki" <rjw@...k.pl>, Pavel Machek <pavel@....cz>,
	Marcus Better <marcus@...ter.se>,
	Andrey Borzenkov <arvidjaar@...l.ru>,
	linux-usb-devel@...ts.sourceforge.net,
	Greg Kroah-Hartman <gregkh@...e.de>,
	"Ken'ichi Ohmichi" <oomichi@....nes.nec.co.jp>
Subject: Re: [2/3] 2.6.22-rc2: known regressions v2

On Fri, May 25, 2007 at 09:33:54AM -0700, Andrew Morton wrote:
> On Fri, 25 May 2007 14:34:56 +0200 Ingo Molnar <mingo@...e.hu> wrote:
> 
> > * Chris Newport <crn@...unix.com> wrote:
> > 
> > > There is a fundamental problem in getting a decent log to debug a 
> > > crashed kernel.  Maybe we should take a hint from Solaris. If the 
> > > kernel crashes Solaris dumps core to swap and sets a flag. At the next 
> > > boot this image is copied to /var/adm/crashdump where it is preserved 
> > > for future debugging. Obviously swap needs to be larger than core, but 
> > > this is usually the case.
> > 
> > we've got kdump, but it's not usually enabled by default by distros.
> 
> Isn't that awful?
> 

I think kdump should be enabled by default. Or at least user should be
given an option to enable/configure this service at installation time.

Things are still good atleast in RHEL5. It gives user a option to
enable/disable kdump at firstboot after installation. A fall side of
doing it at firstboot time is that a user has to go for an extra reboot
if he chooses to enable kdump (Because of kernel command line crashkernel=).
An improvemnt could be that these options should be given at installation
time so that a user does not have to go through an extra reboot to enable
kdump service. 

It also has got graphical scripts to configure kdump serivce and enable it.
Other distributions are catching up but there seems to be a reluctance
to enable kdump by default primarily because of a chunk of memory being
reserved for kdump kernel which can not be used by regular kernel.

As of today RHEL reserves 128MB of memory for x86/x86_64 arch if kdump
is enabled. Some people are also reluctant to change the installer to
include a screen which can help user enable/disable/configure kdump. They
think it increases installer complexity and user is likely to get confused.

> By now we should be in the situation where if a tester is hitting a
> kernel crash we can say to them "please turn on crashdumps and send me
> the image".  But we're not - kernel developers don't know how to turn the
> thing on in $RANDOM_DISTRO, testers have no experience with the feature
> and kernel developers don't have experience handling the crash images.
> 
> And I'm not sure that the (required) "don't dump user memory and pagecache"
> feature has been implemented yet?
> 

Yes. It has been implemented and integrated with RHEL5. Not sure about others.
NEC developers have developed a user space filtering utility which can filter
out pagecache, user memory and zero pages.

http://sourceforge.net/projects/makedumpfile

In RHEL5, one can pre-configure filtering options and a filtered crash
dump will automatically be saved to user configured destination.

Thanks
Vivek

-
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/