On 06/10/2022 20:32, Kees Cook wrote: > [...] > Doing a mount will override the result, so I wonder if there should be > two variables, etc... not a concern for the normal use case. > > Also, I've kind of wanted to get rid of a "default" for this and instead > use a value based on the compression vs record sizes, etc. But I didn't > explore it. > For some reason I forgot to respond that, sorry! I didn't understand exactly how the mount would override things; I've done some tests: (1) booted with the new kmsg_bytes module parameter set to 64k, and it was preserved across multiple mount/umount cycles. (2) When I manually had "-o kmsg_bytes=16k" set during the mount operation, it worked as expected, setting the thing to 16k (and reflecting in the module parameter, as observed in /sys/modules). Maybe I'm missing something? Now, regarding the idea of setting that as a function of compression/record_sizes, I feel it makes sense and could be worked, like a heuristic right? In the end, if you think properly, what is the purpose of kmsg_bytes? Wouldn't make sense to just fill the record_size with the maximum amount of data it can handle? Of course there is the partitioning thing, but in the end kmsg_bytes seems a mechanism to _restrict_ the data collection, so maybe the default would be a value that means "save whatever you can handle" (maybe 0), and if the parameter/mount option is set, then pstore would restrict the saved size. Thoughts? Thanks, Guilherme
