linux-kernel - RE: [PATCH 0/5] Persist printk buffer across reboots.

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] [day] [month] [year] [list]

Message-ID: <5C4C569E8A4B9B42A84A977CF070A35B2E31C6F891@USINDEVS01.corp.hds.com>
Date:	Thu, 15 Mar 2012 18:10:29 -0400
From:	Seiji Aguchi <seiji.aguchi@....com>
To:	Daniel Walker <dwalker@...o99.com>,
	Andrew Morton <akpm@...ux-foundation.org>
CC:	Avery Pennarun <apenwarr@...il.com>,
	Josh Triplett <josh@...htriplett.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Ingo Molnar <mingo@...e.hu>,
	"David S. Miller" <davem@...emloft.net>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	"Fabio M. Di Nitto" <fdinitto@...hat.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Olaf Hering <olaf@...fle.de>,
	Paul Gortmaker <paul.gortmaker@...driver.com>,
	Tejun Heo <tj@...nel.org>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Yinghai LU <yinghai@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"Luck, Tony (tony.luck@...el.com)" <tony.luck@...el.com>
Subject: RE: [PATCH 0/5] Persist printk buffer across reboots.

Hi,

> There is also this series,
> 
> http://lists.infradead.org/pipermail/kexec/2011-July/005258.html
> 
> It seems awkward that pstore is in fs/pstore/ then pstore ends up as the "back end" where it could just be the whole solution.

I just wanted to avoid deadlocks of pstore and its drivers such as mtdoops, ramoops, and efi_pstore in panic case.
That is still under discussion in lkml.

I have no objection to modifying mtdoops/ram_console to use pstore.

>pstore does seems to have the nicest user interface (might be better in debugfs tho). If someone wanted to move forward with pstore they would have to write some some sort of,
>
>int pstore_register_simple(unsigned long addr, unsigned long size);
>
>to cover all the memory areas that aren't transaction based, or make pstore accept a platform_device.

If you would like to introduce new feature to pstore, Tony Luck is the appropriate person to discuss.

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