linux-kernel - Re: [PATCH 04/11] persistent_ram: Introduce persistent_ram

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:	Tue, 15 May 2012 17:22:33 -0700
From:	Anton Vorontsov <anton.vorontsov@...aro.org>
To:	Colin Cross <ccross@...roid.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Kees Cook <keescook@...omium.org>,
	Arnd Bergmann <arnd@...db.de>,
	John Stultz <john.stultz@...aro.org>, arve@...roid.com,
	Rebecca Schultz Zavin <rebecca@...roid.com>,
	Jesper Juhl <jj@...osbits.net>,
	Randy Dunlap <rdunlap@...otime.net>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Thomas Meyer <thomas@...3r.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Marco Stornelli <marco.stornelli@...il.com>,
	WANG Cong <xiyou.wangcong@...il.com>,
	linux-kernel@...r.kernel.org, devel@...verdev.osuosl.org,
	linaro-kernel@...ts.linaro.org, patches@...aro.org,
	kernel-team@...roid.com
Subject: Re: [PATCH 04/11] persistent_ram: Introduce persistent_ram_new()

Hello Colin,

On Mon, May 14, 2012 at 05:37:56PM -0700, Colin Cross wrote:
[...]
> even worse, mem= from the bootloader.  Mixing the two methods together
> would be confusing.

Yes, mixing is discouraged. The mem= hack is mostly useful for
developers, for hacking random kernels. Even on x86 it is
useful, when you want to grab an oops, but you don't have say
netconsole, or HW really screwed up and you don't have any
means to get the oops log, ramoops may become quite useful.

But in the Android phone scenario, if you want to have this
feature into production kernels, platforms should register
the ramoops platform driver, as they were doing before.

> Either persistent_ram_early_init should be
> removed completely (or replaced with something that is easier to
> register ramoops into), or ramoops should use
> persistent_ram_init_ringbuffer like ram_console does.

Yep, this was indeed my original idea: persistent_ram_early_init
should go.

Boards (or generic arch/ or arch/mach-* code that knows memory
layout) will have to just do two things:

1. Wisely and early call memblock_reserve().
2. Register a ramoops platform device pointing to the reserved
   memory.

This is actually exactly the same as you were doing with
ram_console:

1. Platform were adding an entry to the global list of persistent
   ram zones, and then were calling persistent_ram_early_init()
   somewhere in the arch/ code (at least that's how I understood
   the idea of the code, as there are currently no in-tree users).
2. Then platforms were registering a ram_console platform device,
   and the driver would find out the needed zone by matching on
   the device name.

Thinking about it, the whole thing was actually abusing
the device-driver model a little bit. So things are just easier
now.

Thanks!

-- 
Anton Vorontsov
Email: cbouatmailru@...il.com
--
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/