Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933244Ab0LTVJp (ORCPT ); Mon, 20 Dec 2010 16:09:45 -0500 Received: from mail-iw0-f194.google.com ([209.85.214.194]:43086 "EHLO mail-iw0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933068Ab0LTVJm (ORCPT ); Mon, 20 Dec 2010 16:09:42 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=LwGyfFrAyLFpimLuGKM76vLX6LbSkEh20UfMXZRa4TQuw5l7a3mNm2P8UK7DXe417h fVEKVoPNpIzOnMzAgvXzRrCjVziHIc4XYw/sTL5lrEPmQ7ughoW6FGoMdqAiwMNHn4a/ 0zogs4zBrKmsGG0BWLboD0yG39iCI0g65zQ/s= MIME-Version: 1.0 In-Reply-To: <20101220185812.GA11285@liondog.tnic> References: <4D0BEE1F.7020008@zytor.com> <20101219091752.GA16150@liondog.tnic> <20101220072632.GA28020@liondog.tnic> <20101220185812.GA11285@liondog.tnic> Date: Mon, 20 Dec 2010 13:09:41 -0800 X-Google-Sender-Auth: PgZGQcw2Z1moQmDlOLjsgMue5ss Message-ID: Subject: Re: [concept & "good taste" review] persistent store From: Tony Luck To: Borislav Petkov , Linus Torvalds , Tony Luck , Tony Luck , "H. Peter Anvin" , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, tglx@linutronix.de, mingo@elte.hu, greg@kroah.com, akpm@linux-foundation.org, ying.huang@intel.com, David Miller , Alan Cox , Jim Keniston , Kyungmin Park , Geert Uytterhoeven Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 960 Lines: 21 On Mon, Dec 20, 2010 at 10:58 AM, Borislav Petkov wrote: > Yes, this was exactly what I was trying to say! Do something in a > watchdog handler path that shows that we actually made progress. But > you're right, we'd still need the notification. My look at "did we make > a progress" was too simple and there _are_ nuances which need to be > accounted for. My view of the notification is: 1) Oops happens, gets written to persistent store. 2) fs/pstore code makes a file appear in /dev/pstore 3) Daemon that's watching /dev/pstore sees new file 4) File is read, copied some place safe and fsync'd 5) Daemon unlinks file from /dev/pstore 6) fs/pstore code tells platform level to erase record -Tony -- 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/