Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754013Ab3F0PgI (ORCPT ); Thu, 27 Jun 2013 11:36:08 -0400 Received: from mail-ie0-f169.google.com ([209.85.223.169]:44136 "EHLO mail-ie0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751796Ab3F0PgF (ORCPT ); Thu, 27 Jun 2013 11:36:05 -0400 MIME-Version: 1.0 In-Reply-To: <20130627082941.16749.67023.stgit@aruna-ThinkPad-T420> References: <20130627082941.16749.67023.stgit@aruna-ThinkPad-T420> Date: Thu, 27 Jun 2013 08:36:05 -0700 X-Google-Sender-Auth: FBJebdDn8oo3JDRfdSpsVjpNXN8 Message-ID: Subject: Re: [PATCH v2 0/3] Nvram-to-pstore: compression support for oops data From: Kees Cook To: Aruna Balakrishnaiah Cc: Tony Luck , benh@kernel.crashing.org, LKML , linuxppc-dev@ozlabs.org, paulus@samba.org, jkenisto@linux.vnet.ibm.com, ananth@in.ibm.com, mahesh@linux.vnet.ibm.com, Anton Vorontsov , Anton Blanchard , Colin Cross 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: 1907 Lines: 49 On Thu, Jun 27, 2013 at 1:32 AM, Aruna Balakrishnaiah wrote: > Changes from v1: > - Add header size argument in the pstore write callback > instead of a separate API to return header size. > > The patchset takes care of compressing oops messages while writing to NVRAM, > so that more oops data can be captured in the given space. > > big_oops_buf (2.22 * oops_data_sz) is allocated for compression. > oops_data_sz is oops header size less of oops partition size. > > Pstore will internally call kmsg_dump to capture messages from printk > buffer. While returning the data to nvram it adds is own header. > > For compression: > Register pstore with big_oops_buf. > > In case compression fails, copy header added by pstore and > last oops_data_sz bytes (recent messages) of big_oops_buf to > nvram for which we need to know header size. > > patch 01/03 adds an additional argument for header size in pstore_write callback. > > pstore read callback of nvram will read the compressed data and return the > decompressed data so that dmesg file (under /dev/pstore) is readable. > > In case decompression fails, instead of having the compressed data (junk) in the > dmesg file it will skip and continue reading other partitions. This results in > absence of dmesg file but will still have files relating to other parititons. This seems good to me. I'm starting to ponder if we need to have some kind of regular header structure that backends can extend, but that doesn't need to be part of this series. :) Acked-by: Kees Cook Thanks, -Kees -- Kees Cook Chrome OS Security -- 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/