linux-kernel - Re: pstore/ramoops - why only collect a partial dmesg?

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: <0ca4c27a-a707-4d36-9689-b09ef715ac67@igalia.com>
Date:   Tue, 4 Jan 2022 09:17:59 -0300
From:   "Guilherme G. Piccoli" <gpiccoli@...lia.com>
To:     "Luck, Tony" <tony.luck@...el.com>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "anton@...msg.org" <anton@...msg.org>,
        "ccross@...roid.com" <ccross@...roid.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linux-Fsdevel <linux-fsdevel@...r.kernel.org>,
        "Guilherme G. Piccoli" <kernel@...ccoli.net>
Subject: Re: pstore/ramoops - why only collect a partial dmesg?

On 03/01/2022 20:31, Luck, Tony wrote:
> Guilherme,
> 
> The efi (and erst) backends for pstore have severe limitations on the size
> of objects that can store (just a few Kbytes) so pstore breaks the dmesg
> data into pieces.
> 
> I'm not super-familiar with how ramoops behaves, but maybe it allows setting
> a much larger "record_size" ... so this split isn't needed?
> 
> -Tony
> 

Hi Tony, thanks a lot for your response! It makes sense indeed, but in
my case, for example, I have a "log_buf_len=4M", but cannot allocate a
4M record_size - when I try that, I can only see page_alloc spews and
pstore/ramoops doesn't work. So, I could allocate 2M and that works
fine, but I then lose half of my dmesg heh
Hence my question.

If there's no special reason, I guess would make sense to allow ramoops
to split the dmesg, what do you think?
Cheers,

Guilherme