[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <267ccf8f-1fea-7648-ec2b-e7f4ae822ae4@igalia.com>
Date: Wed, 12 Oct 2022 12:33:36 -0300
From: "Guilherme G. Piccoli" <gpiccoli@...lia.com>
To: Kees Cook <keescook@...omium.org>
Cc: linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
kernel-dev@...lia.com, kernel@...ccoli.net, anton@...msg.org,
ccross@...roid.com, tony.luck@...el.com
Subject: Re: [PATCH 2/8] pstore: Expose kmsg_bytes as a module parameter
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
Powered by blists - more mailing lists