Messages in this thread | | | Date | Fri, 19 Feb 2021 01:54:23 +0100 | From | Jiri Bohac <> | Subject | Re: pstore: fix compression |
| |
On Thu, Feb 18, 2021 at 12:30:03PM -0800, Kees Cook wrote: > Eek; thanks for the catch!
thanks for applying the fix;
BTW, with the compression broken, I was not getting any dmesg stored in ERST at all, not even uncompressed. After instrumenting the code with a lot of debug printks I found that writing erst_erange.size worth of data into the ERST fails and the maximum writeable size is 98 bytes smaler:
Details:
- erst_erange.size = 65536 - this results in erst_info.bufsize = 65336 - pstore_compress() returned -EINVAL (because of the just-fixed typo), zipped_len = -EINVAL. - pstore_dump calls copy_kmsg_to_buffer to only copy bufsize bytes from big_oops_buf to psinfo->buf; record.size = bufsize = 65336
psinfo->write(&record) then fails with -EINVAL; by more tracing inside the ERST code I found the -EINVAL was produced by __erst_write_to_storage() after apei_exec_ctx_get_output() returned val=ERST_STATUS_FAILED=3 and this got translated into -EINVAL by erst_errno().
Once the compression was fixed everything started working because the records are much smaller after the compression (~30kB).
My next thought was to find the largest possible record that could be written successfully. I modified the ERST init code to decrease erst_info.bufsize by a value specified on the cmdline. The maximum writable record was 65238 bytes long (i.e. erst_erange.size - sizeof(struct cper_pstore_record) - 98). With this hack I got 65238 bytes of uncompressed dmesg stored to ERST.
Any idea what might be causing this? As far as I can tell, there are no other records in the ERST (checked through the erst-dbg interface). Tested on a HPE ProLiant DL120 Gen10 server.
Thanks!
-- Jiri Bohac <jbohac@suse.cz> SUSE Labs, Prague, Czechia
| |