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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 19 Sep 2014 09:22:36 -0400 From: Vivek Goyal <vgoyal@...hat.com> To: CAI Qian <caiqian@...hat.com> Cc: linux-kernel <linux-kernel@...r.kernel.org>, ltp-list <ltp-list@...ts.sourceforge.net>, crash-utility <crash-utility@...hat.com>, kexec <kexec@...ts.infradead.org>, kexec kdump redhat mailing list <kexec-kdump-list@...hat.com> Subject: Re: [RFC] autokdump - automated kdump testsuite On Fri, Sep 19, 2014 at 05:52:25AM -0400, CAI Qian wrote: > I plan to release an automated kdump testsuite that will be So will this be a standalone test suit? Can it be merged with something already existing say, LTP. > focus on testing kernel and the crash utility. It should work > for all major distros since it will use none of distro-specific > stuff, and also support different arches including x86, ARM, > PPC64 and s390x. > > It does the following: > 1) check if there is a memory reserved for kdump. If not, > reserve the memory and reboot the system. > 2) once the system is back, load kexec on panic and > prepare a separate initramfs that including needed > modules to load a local filesystem and necessary utilities So you will write logic to prepare custom initramfs or will rely on dracut or some other utility for that. > in order to analyse /proc/vmcore in the 2nd kernel. > 3) trigger the system crash using methods like sysrq-c, NMI, > and panic_on_hung_task etc. > 4) in the 2nd kernel, mount a filesystem and use the crash > utility to analyse /proc/vmcore. Then, gather the analyse > logs, serial console output, dmesg etc into the filesystem. Why not save core and boot back in first kernel and then analyze. Trying to work directly with /proc/vmcore does not test makedumfile which everybody uses. Also it will require more memory to be reserved and packing crash and debug vmlinux into initramfs. I think being able to test makedumpfile also is the key here. Thanks Vivek > 5) reboot back into the 1st kernel. > > implementation: > It will setup a daemon to handle reboots. > > plan: > I might also to test the makedumpfile all together later. > CAI Qian -- 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/
Powered by blists - more mailing lists