On Fri, 13 Mar 2026 17:57:35 -0300 "Guilherme G. Piccoli" <[email protected]> wrote:
> Hi Steve, this is very interesting! Thanks for pointing that > infrastructure. And I'm glad it confirms my impression that the full fix > of that isn't trivial heh > > 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!) -- Steve > > I'll wait a bit more to see what pstore maintainers think about that, if > is worth to have the very simple KASLR fix or a bit more engineered > solution that factors modules as well.
