Re: [PATCH] pstore/ftrace: Factor KASLR offset in the core kernel instruction addresses

Guilherme G. Piccoli
2026-03-15T15:02:27Z

On 15/03/2026 11:09, Steven Rostedt wrote:
> On Fri, 13 Mar 2026 17:57:35 -0300
> [...]
>> So, are you suggesting to use the ftrace infrastructure in the
>> pstore/ftrace? Well, seeing how mature the ftrace infra is with regards
>> the persistent ring buffer, I'd say pstore/ftrace+ramoops gets useless
>> now heh
>
> The persistent ring buffer only works when the memory is reliably
> consistent between soft reboots. It doesn't work for any other pstore
> interface. Thus, if you can rely on normal ram being available across
> reboots, then use ftrace. If not, then you have to use pstore. Hence,
> it doesn't make pstore useless.
>
> I would not use the ftrace scratchpad for pstore, as if that works,
> then just use ftrace ;-)
>
>>
>> The usage then for pstore/ftrace would be more with other backends,
>> really low memory cases like ERST or UEFI, for example, in embedded
>> maybe. And in this case, saving the full modules name table + offsets
>> could incur some precious memory consumption and/or performance impact.
>> Or maybe I'm talking nonsense and this would be quite OK ... guess worth
>> taking a look.
>
> Exactly (I wrote the above before reading this paragraph!)

Perfect, thanks for confirming. I think the idea of factoring KASLR on
pstore/ftrace (in a simple way) is then valid ... let's see others'
opinions =)

Cheers,

Guilherme