Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: - [Low] The commit message claims that all `kernel_param_ops` initializers in the tree now use the `DEFINE_KERNEL_PARAM_OPS` macro, but several files (e.g., `arch/xtensa/platforms/iss/simdisk.c`, `drivers/video/fbdev/uvesafb.c`, `drivers/mtd/ubi/block.c`, `drivers/target/target_core_user.c`) still use direct struct initialization. - [Low] Renaming the `.get` field to `.get_str` in `struct kernel_param_ops` breaks the kernel build when Rust is enabled (`CONFIG_RUST=y`). --
commit 1952ed67c747da9c1d8185a27ee2651d4cdb0689 Author: Kees Cook <[email protected]> moduleparam: Rename .get field to .get_str This commit renames the .get callback in struct kernel_param_ops to .get_str. It frees up the .get name for a future commit that will re-add it as a seq_buf-based callback. > Now that every kernel_param_ops initializer in the tree goes through > DEFINE_KERNEL_PARAM_OPS, no source file outside kernel/params.c and [Severity: Low] This isn't a bug, but is this description entirely accurate? Several files like arch/xtensa/platforms/iss/simdisk.c, drivers/video/fbdev/uvesafb.c, and drivers/mtd/ubi/block.c still use direct struct initialization because they only define .set. > include/linux/moduleparam.h references the .get field by name. Take > advantage of that to rename the field to .get_str. [ ... ] > diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h > index 26bf45b36d023..f5f4148e25049 100644 > --- a/include/linux/moduleparam.h > +++ b/include/linux/moduleparam.h > @@ -63,7 +63,7 @@ struct kernel_param_ops { > /* Returns 0, or -errno. arg is in kp->arg. */ > int (*set)(const char *val, const struct kernel_param *kp); > /* Returns length written or -errno. Buffer is 4k (ie. be short!) */ > - int (*get)(char *buffer, const struct kernel_param *kp); > + int (*get_str)(char *buffer, const struct kernel_param *kp); [Severity: Low] Does this break the kernel build when CONFIG_RUST=y? In rust/kernel/module_param.rs, the make_param_ops! macro explicitly initializes the generated C struct with get: None. When bindgen reflects the renamed field, compilation will fail because the get field no longer exists and the new get_str field is uninitialized. Even though this is resolved later in the series by removing the get_str field entirely, does this intermediate breakage cause issues for git bisect? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=5
