To:     keescook@chromium.org, anton@enomsg.org, ccross@android.com,
        tony.luck@intel.com
Cc:     linux-kernel@vger.kernel.org,
        Linux-Fsdevel <linux-fsdevel@vger.kernel.org>,
        gpiccoli@igalia.com, "Guilherme G. Piccoli" <kernel@gpiccoli.net>
From:   "Guilherme G. Piccoli" <gpiccoli@igalia.com>
Subject: pstore/ramoops - why only collect a partial dmesg?
Message-ID: <a21201cf-1e5f-fed1-356d-42c83a66fa57@igalia.com>
Date:   Wed, 29 Dec 2021 11:43:51 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.14.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi Anton / Colin / Kees / Tony, I'd like to understand the rationale
behind a ramoops behavior, appreciate in advance any information/advice!

I've noticed that while using ramoops as a backend for pstore, only the
first "record_size" bytes of dmesg is collected/saved in sysfs on panic.
It is the "Part 1" of dmesg - seems this is on purpose [0], so I'm
curious on why can't we save the full dmesg split in multi-part files,
like efi-pstore for example?

If that's an interesting idea, I'm willing to try implementing that in
case there are no available patches for it already (maybe somebody
worked on it for their own usage). My idea would be to have a tuning to
enable or disable such new behavior, and we could have files like
"dmesg-ramoops-0.partX" as the partitions of the full "dmesg-ramoops-0".

Thanks in advance,


Guilherme


[0]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/pstore/ram.c#n353