[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANiq72=B9s4+4BhezmDPWc6K9tYvhyNpw9uWnRhVdymSUAO_sA@mail.gmail.com>
Date: Tue, 5 Sep 2023 21:36:01 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Kees Cook <keescook@...omium.org>
Cc: Luis Chamberlain <mcgrof@...nel.org>,
Johan Hovold <johan@...nel.org>, Jessica Yu <jeyu@...nel.org>,
Sagi Grimberg <sagi@...mberg.me>,
Nick Desaulniers <ndesaulniers@...ogle.com>,
Miguel Ojeda <ojeda@...nel.org>, Joe Perches <joe@...ches.com>,
Azeem Shaikh <azeemshaikh38@...il.com>,
linux-modules@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-hardening@...r.kernel.org
Subject: Re: [PATCH] module: Clarify documentation of module_param_call()
On Tue, Sep 5, 2023 at 9:13 PM Kees Cook <keescook@...omium.org> wrote:
>
> Commit 9bbb9e5a3310 ("param: use ops in struct kernel_param, rather than
> get and set fns directly") added the comment that module_param_call()
> was deprecated, during a large scale refactoring to bring sanity to type
> casting back then. In 2017 following more cleanups, it became useful
> against as it wraps a common pattern of creating an ops struct for a
s/against/again/
> Many users of module_param_cb() appear to be almost universally
> open-coding the same thing that module_param_call() does now. Don't
> discourage[1] people from using module_param_call() but clarifying the
> comment: module_param_cb() is useful if you repeatedly use the same pair
> of get/set functions.
s/clarifying/clarify/
I sampled some, and indeed many define the ops struct.
> [1] https://lore.kernel.org/lkml/202308301546.5C789E5EC@keescook/
Link: tag here? It is actually quite nicely explained there.
> -/* Obsolete - use module_param_cb() */
> +/* For repeated _set & _get usage use module_param_cb() */
Perhaps add "instead"? Or perhaps add a bit more detail, something like:
Useful for describing a set/get pair used only once (i.e. for this
parameter). For repeated set/get pairs (i.e. the same kernel_param_ops
struct), use module_param_cb() instead.
Reviewed-by: Miguel Ojeda <ojeda@...nel.org>
Cheers,
Miguel
Powered by blists - more mailing lists