linux-kernel - Re: [concept & "good taste" review] persistent store

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: <20101221074259.GB32278@liondog.tnic>
Date:	Tue, 21 Dec 2010 08:42:59 +0100
From:	Borislav Petkov <bp@...en8.de>
To:	Tony Luck <tony.luck@...el.com>
Cc:	Huang Ying <ying.huang@...el.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"mingo@...e.hu" <mingo@...e.hu>, "greg@...ah.com" <greg@...ah.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	David Miller <davem@...emloft.net>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Jim Keniston <jkenisto@...ux.vnet.ibm.com>,
	Kyungmin Park <kmpark@...radead.org>,
	Geert Uytterhoeven <geert@...ux-m68k.org>
Subject: Re: [concept & "good taste" review] persistent store

On Mon, Dec 20, 2010 at 09:13:33PM -0800, Tony Luck wrote:
> On Mon, Dec 20, 2010 at 4:48 PM, Huang Ying <ying.huang@...el.com> wrote:
> > If persistent storage driver (such as ERST) implements kmsg_dumper by
> > themselves, that should be easier to use multiple records for one
> > message dumping request.
> 
> Or I can build it into the fs/pstore layer. If the record size looks too
> small[*], loop writing multiple records (starting with the tail of the buffer,
> so that if the persistent store fills up, we are sure to have the stack
> back trace and register dump).

Wait a second, isn't this loop writing actually what we want?!

I mean, if the pstore is big enough to contain, say the last ca. 50 or
so oops messages (this size should suffice even for OOMkill oopses),
we do make sure that we always have the last set of oopses belonging
together and thus if we panic, we have also the relevant ones.

 [ IIRC, each ERST record can contain roughly 8K, and we want 50 of
 those so having a 1M flash on the platform isn't science fiction
 anymore, no? ]

By loop writing it, we also make sure we overwrite the oldest oopses
which, if the pstore is big enough, shouldn't have anything to do with
the next set to be written.

So, basically designing the pstore as a big enough circular buffer
should suffice, no?

This would even alleviate the need for the notification heuristics and
writeout to userspace.

Hmm...

-- 
Regards/Gruss,
    Boris.
--
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/