Re: [GIT PULL] pstore updates for v6.6-rc1

[Linus Torvalds]

On Mon, 28 Aug 2023 at 18:28, Kees Cook <kees@xxxxxxxxxx> wrote:
>
> - does this happen at every boot? (I assume yes.)

Yes so far. I don't boot between every pull, so I think I've only had
two boots since the pstore pull, but both of them have this.

I also see it on my laptop, so it's not hw-specific.

> - what CONFIG are you built with?

I'll send my config separately in private, I don't think we want to
have that kind of noisy thing on the list. But it's basically a
standard Fedora config, cut down with "make localmodconfig" and with
some of the more annoying options disabled.

> - what was the prior CONFIG?

No changes, apart from "make oldconfig".

> - what backend is in use? (Or better yet, what does "dmesg | grep pstore" report?)

  [torvalds@ryzen linux]$ dmesg -t | grep pstore
  pstore: Using crash dump compression: deflate
  pstore: Registered efi_pstore as persistent store backend
  pstore: zlib_inflate() failed, ret = -5!
  pstore: zlib_inflate() failed, ret = -5!
  .. repeats a lot ..

> - are you using systemd?

Yup. Standard F37 install - except for the kernel, of course.

It does happen right after

  Write protecting the kernel read-only data: 22528k
  Freeing unused kernel image (rodata/data gap) memory: 224K
  Run /init as init process
    with arguments:
      /init
      rhgb
    with environment:
      HOME=/
      TERM=linux
      BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.5.0-00771-g5af3e822077e
      resume=/dev/mapper/fedora_localhost--live-swap
  [ lots of "pstore: zlib_inflate() failed, ret = -5!" ]

and just before systemd adds

  systemd[1]: systemd 251.14-2.fc37 running in system mode (+PAM
+AUDIT +SELINUX -APPARMOR +IMA +SMAC>
  systemd[1]: Detected architecture x86-64.

to the logs.

Which could easily mean that it's triggered by something systemd does
very early.

But none of those other messages are new, and that systemd version
that it reports is the same it has reported before (without any storm
of zlib_inflate() error messages).

> Let me think about the best way to deal with this. I expect I'll have pstore wipe the failed records as it is expressly not expected to work across differing configs/kernel versions. And permanently spewing errors is not ok.

So none of that sounds new.

The only thing that is new is the kernel pstore implementation. Why
was this not a problem before? The warning existed back then too, but
I never actually got it.

I get the feeling that you are overlooking that basic fact.

                 Linus