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: <CAMbhsRRTFY-U7e4ifoDKjgy9mQj+p79aa52U=PoOmwBxjpLXNg@mail.gmail.com>
Date:	Fri, 18 May 2012 16:42:03 -0700
From:	Colin Cross <ccross@...roid.com>
To:	Anton Vorontsov <anton.vorontsov@...aro.org>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Kees Cook <keescook@...omium.org>,
	Tony Luck <tony.luck@...el.com>, Arnd Bergmann <arnd@...db.de>,
	John Stultz <john.stultz@...aro.org>,
	Shuah Khan <shuahkhan@...il.com>, 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 03/14] pstore/ram_core: Do not reset restored zone's
 position and size

On Fri, May 18, 2012 at 3:24 PM, Anton Vorontsov
<anton.vorontsov@...aro.org> wrote:
> Otherwise, the files will survive just one reboot, and on a subsequent
> boot they will disappear.
>
> Signed-off-by: Anton Vorontsov <anton.vorontsov@...aro.org>
> ---
>  fs/pstore/ram_core.c |    1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
> index 849a542..dff5127 100644
> --- a/fs/pstore/ram_core.c
> +++ b/fs/pstore/ram_core.c
> @@ -422,6 +422,7 @@ static int __init persistent_ram_post_init(struct persistent_ram_zone *prz, bool
>                                " size %zu, start %zu\n",
>                               buffer_size(prz), buffer_start(prz));
>                        persistent_ram_save_old(prz);
> +                       return 0;
>                }
>        } else {
>                pr_info("persistent_ram: no valid data in buffer"
> --
> 1.7.9.2
>

This causes an interesting behavior change in the console logging.
Before this change, the console log would show only the messages from
the last reboot.  After this change, the console log will have logs
from multiple boots appended to each other.  I can think of some
places where that could very handy, so I'm not against the change, but
as is it makes reading the logs much harder - the first oops you see
while skimming the log may not be from the last reboot.

One possibility would be to insert an obvious (and script parseable)
header during probe to separate the boots.  Another option would be to
expand the ringbuffer metadata to contain duplicate start and size
fields that only cover the most recent reboot, and export two files,
console-ramoops that contains the last log, and console-all-ramoops
that contains all the logs.  Or you could just zap the console buffer
at boot to keep the old behavior.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ