linux-kernel - RE: pstore dump inside an nmi handler

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]

Date:	Wed, 13 Jul 2011 09:58:18 -0700
From:	"Luck, Tony" <tony.luck@...el.com>
To:	Don Zickus <dzickus@...hat.com>
CC:	"mjg@...hat.com" <mjg@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Huang, Ying" <ying.huang@...el.com>
Subject: RE: pstore dump inside an nmi handler

> Actually, is it expected that the ERST can handle only 8 records?  Also if
> you remove those records with pstore mount under /mnt; 'rm -rf
> /mnt/dmesg-*', are those records removed immediately or are they cached to
> be removed later?  IOW, if a did a 'rm -rf ..' and then an 'echo c >
> /proc/sysrq-trigger' immediately after it, would I expect those records to
> be removed or not?  Testing shows they are removed on reboot but the later
> 'echo c > ..' didn't save any new error records. :-/

It isn't specified how much storage will be provided by ERST.  I tried to
find a limit on the system on which I did the original development, but
got bored at a hundred ... which seemed to be plenty enough since the usual
mode of operation ought to be to copy the records from pstore to some other
storage and remove them from pstore early in boot.

The unlink from pstore is passed immediately to the backing store to
do it's clear/erase operation ... but whether the BIOS implementation
of ERST makes that space immediately available might vary from platform
to platform.

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