* Re: [PATCH] params: Replace __modinit with __init_or_module
From: Daniel Gomez @ 2025-10-22 22:55 UTC (permalink / raw)
To: Petr Pavlu, Luis Chamberlain, Sami Tolvanen
Cc: Shyam Saini, Rasmus Villemoes, linux-modules, linux-kernel
In-Reply-To: <20250819121248.460105-1-petr.pavlu@suse.com>
On 19/08/2025 14.12, Petr Pavlu wrote:
> Remove the custom __modinit macro from kernel/params.c and instead use the
> common __init_or_module macro from include/linux/module.h. Both provide the
> same functionality.
>
> Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
Reviewed-by: Daniel Gomez <da.gomez@samsung.com>
> ---
> kernel/params.c | 15 +++++----------
> 1 file changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/kernel/params.c b/kernel/params.c
> index b92d64161b75..19bb04f10372 100644
> --- a/kernel/params.c
> +++ b/kernel/params.c
> @@ -595,12 +595,6 @@ static ssize_t param_attr_store(const struct module_attribute *mattr,
> }
> #endif
>
> -#ifdef CONFIG_MODULES
> -#define __modinit
> -#else
> -#define __modinit __init
> -#endif
> -
> #ifdef CONFIG_SYSFS
> void kernel_param_lock(struct module *mod)
> {
> @@ -625,9 +619,9 @@ EXPORT_SYMBOL(kernel_param_unlock);
> * create file in sysfs. Returns an error on out of memory. Always cleans up
> * if there's an error.
> */
> -static __modinit int add_sysfs_param(struct module_kobject *mk,
> - const struct kernel_param *kp,
> - const char *name)
> +static __init_or_module int add_sysfs_param(struct module_kobject *mk,
> + const struct kernel_param *kp,
> + const char *name)
> {
> struct module_param_attrs *new_mp;
> struct attribute **new_attrs;
> @@ -760,7 +754,8 @@ void destroy_params(const struct kernel_param *params, unsigned num)
> params[i].ops->free(params[i].arg);
> }
>
> -struct module_kobject __modinit * lookup_or_create_module_kobject(const char *name)
> +struct module_kobject * __init_or_module
> +lookup_or_create_module_kobject(const char *name)
> {
> struct module_kobject *mk;
> struct kobject *kobj;
>
> base-commit: be48bcf004f9d0c9207ff21d0edb3b42f253829e
^ permalink raw reply
* Re: [PATCH] module: Remove unused __INIT*_OR_MODULE macros
From: Daniel Gomez @ 2025-10-22 22:55 UTC (permalink / raw)
To: Petr Pavlu, Luis Chamberlain, Sami Tolvanen; +Cc: linux-modules, linux-kernel
In-Reply-To: <20250819121423.460156-1-petr.pavlu@suse.com>
On 19/08/2025 14.13, Petr Pavlu wrote:
> Remove the __INIT_OR_MODULE, __INITDATA_OR_MODULE and
> __INITRODATA_OR_MODULE macros. These were introduced in commit 8b5a10fc6fd0
> ("x86: properly annotate alternatives.c"). Only __INITRODATA_OR_MODULE was
> ever used, in arch/x86/kernel/alternative.c. In 2011, commit dc326fca2b64
> ("x86, cpu: Clean up and unify the NOP selection infrastructure") removed
> this usage.
>
> Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
Reviewed-by: Daniel Gomez <da.gomez@samsung.com>
> ---
> include/linux/module.h | 6 ------
> 1 file changed, 6 deletions(-)
>
> diff --git a/include/linux/module.h b/include/linux/module.h
> index 3319a5269d28..e9e6eeb042aa 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -151,16 +151,10 @@ extern void cleanup_module(void);
> #define __init_or_module
> #define __initdata_or_module
> #define __initconst_or_module
> -#define __INIT_OR_MODULE .text
> -#define __INITDATA_OR_MODULE .data
> -#define __INITRODATA_OR_MODULE .section ".rodata","a",%progbits
> #else
> #define __init_or_module __init
> #define __initdata_or_module __initdata
> #define __initconst_or_module __initconst
> -#define __INIT_OR_MODULE __INIT
> -#define __INITDATA_OR_MODULE __INITDATA
> -#define __INITRODATA_OR_MODULE __INITRODATA
> #endif /*CONFIG_MODULES*/
>
> struct module_kobject *lookup_or_create_module_kobject(const char *name);
>
> base-commit: be48bcf004f9d0c9207ff21d0edb3b42f253829e
^ permalink raw reply
* Re: [PATCH v2 10/10] module loader: enforce symbol import protection
From: kernel test robot @ 2025-10-23 2:36 UTC (permalink / raw)
To: Siddharth Nayyar, petr.pavlu
Cc: oe-kbuild-all, arnd, linux-arch, linux-kbuild, linux-kernel,
linux-modules, mcgrof, nathan, nicolas.schier, samitolvanen,
sidnayyar, maennich, gprocida
In-Reply-To: <20251013153918.2206045-11-sidnayyar@google.com>
Hi Siddharth,
kernel test robot noticed the following build errors:
[auto build test ERROR on arnd-asm-generic/master]
[also build test ERROR on soc/for-next linus/master v6.18-rc2 next-20251022]
[cannot apply to mcgrof/modules-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Siddharth-Nayyar/define-kernel-symbol-flags/20251021-104658
base: https://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git master
patch link: https://lore.kernel.org/r/20251013153918.2206045-11-sidnayyar%40google.com
patch subject: [PATCH v2 10/10] module loader: enforce symbol import protection
config: x86_64-randconfig-122-20251022 (https://download.01.org/0day-ci/archive/20251023/202510231021.yaURwkIz-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251023/202510231021.yaURwkIz-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202510231021.yaURwkIz-lkp@intel.com/
All errors (new ones prefixed by >>):
kernel/module/main.c: In function 'resolve_symbol':
>> kernel/module/main.c:1271:37: error: 'struct module' has no member named 'sig_ok'
1271 | if (fsa.is_protected && !mod->sig_ok) {
| ^~
vim +1271 kernel/module/main.c
1228
1229 /* Resolve a symbol for this module. I.e. if we find one, record usage. */
1230 static const struct kernel_symbol *resolve_symbol(struct module *mod,
1231 const struct load_info *info,
1232 const char *name,
1233 char ownername[])
1234 {
1235 struct find_symbol_arg fsa = {
1236 .name = name,
1237 .gplok = !(mod->taints & (1 << TAINT_PROPRIETARY_MODULE)),
1238 .warn = true,
1239 };
1240 int err;
1241
1242 /*
1243 * The module_mutex should not be a heavily contended lock;
1244 * if we get the occasional sleep here, we'll go an extra iteration
1245 * in the wait_event_interruptible(), which is harmless.
1246 */
1247 sched_annotate_sleep();
1248 mutex_lock(&module_mutex);
1249 if (!find_symbol(&fsa))
1250 goto unlock;
1251
1252 if (fsa.license == GPL_ONLY)
1253 mod->using_gplonly_symbols = true;
1254
1255 if (!inherit_taint(mod, fsa.owner, name)) {
1256 fsa.sym = NULL;
1257 goto getname;
1258 }
1259
1260 if (!check_version(info, name, mod, fsa.crc)) {
1261 fsa.sym = ERR_PTR(-EINVAL);
1262 goto getname;
1263 }
1264
1265 err = verify_namespace_is_imported(info, fsa.sym, mod);
1266 if (err) {
1267 fsa.sym = ERR_PTR(err);
1268 goto getname;
1269 }
1270
> 1271 if (fsa.is_protected && !mod->sig_ok) {
1272 pr_warn("%s: Cannot use protected symbol %s\n",
1273 mod->name, name);
1274 fsa.sym = ERR_PTR(-EACCES);
1275 goto getname;
1276 }
1277
1278 err = ref_module(mod, fsa.owner);
1279 if (err) {
1280 fsa.sym = ERR_PTR(err);
1281 goto getname;
1282 }
1283
1284 getname:
1285 /* We must make copy under the lock if we failed to get ref. */
1286 strscpy(ownername, module_name(fsa.owner), MODULE_NAME_LEN);
1287 unlock:
1288 mutex_unlock(&module_mutex);
1289 return fsa.sym;
1290 }
1291
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] module: Remove unused __INIT*_OR_MODULE macros
From: Aaron Tomlin @ 2025-10-23 2:43 UTC (permalink / raw)
To: Petr Pavlu
Cc: Luis Chamberlain, Daniel Gomez, Sami Tolvanen, linux-modules,
linux-kernel
In-Reply-To: <20250819121423.460156-1-petr.pavlu@suse.com>
On Tue, Aug 19, 2025 at 02:13:37PM +0200, Petr Pavlu wrote:
> Remove the __INIT_OR_MODULE, __INITDATA_OR_MODULE and
> __INITRODATA_OR_MODULE macros. These were introduced in commit 8b5a10fc6fd0
> ("x86: properly annotate alternatives.c"). Only __INITRODATA_OR_MODULE was
> ever used, in arch/x86/kernel/alternative.c. In 2011, commit dc326fca2b64
> ("x86, cpu: Clean up and unify the NOP selection infrastructure") removed
> this usage.
>
> Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
> ---
> include/linux/module.h | 6 ------
> 1 file changed, 6 deletions(-)
>
> diff --git a/include/linux/module.h b/include/linux/module.h
> index 3319a5269d28..e9e6eeb042aa 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -151,16 +151,10 @@ extern void cleanup_module(void);
> #define __init_or_module
> #define __initdata_or_module
> #define __initconst_or_module
> -#define __INIT_OR_MODULE .text
> -#define __INITDATA_OR_MODULE .data
> -#define __INITRODATA_OR_MODULE .section ".rodata","a",%progbits
> #else
> #define __init_or_module __init
> #define __initdata_or_module __initdata
> #define __initconst_or_module __initconst
> -#define __INIT_OR_MODULE __INIT
> -#define __INITDATA_OR_MODULE __INITDATA
> -#define __INITRODATA_OR_MODULE __INITRODATA
> #endif /*CONFIG_MODULES*/
>
> struct module_kobject *lookup_or_create_module_kobject(const char *name);
>
> base-commit: be48bcf004f9d0c9207ff21d0edb3b42f253829e
> --
> 2.50.1
>
>
Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
--
Aaron Tomlin
^ permalink raw reply
* Re: [PATCH] params: Replace __modinit with __init_or_module
From: Aaron Tomlin @ 2025-10-23 2:45 UTC (permalink / raw)
To: Petr Pavlu
Cc: Luis Chamberlain, Daniel Gomez, Sami Tolvanen, Shyam Saini,
Rasmus Villemoes, linux-modules, linux-kernel
In-Reply-To: <20250819121248.460105-1-petr.pavlu@suse.com>
On Tue, Aug 19, 2025 at 02:12:09PM +0200, Petr Pavlu wrote:
> Remove the custom __modinit macro from kernel/params.c and instead use the
> common __init_or_module macro from include/linux/module.h. Both provide the
> same functionality.
>
> Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
> ---
> kernel/params.c | 15 +++++----------
> 1 file changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/kernel/params.c b/kernel/params.c
> index b92d64161b75..19bb04f10372 100644
> --- a/kernel/params.c
> +++ b/kernel/params.c
> @@ -595,12 +595,6 @@ static ssize_t param_attr_store(const struct module_attribute *mattr,
> }
> #endif
>
> -#ifdef CONFIG_MODULES
> -#define __modinit
> -#else
> -#define __modinit __init
> -#endif
> -
> #ifdef CONFIG_SYSFS
> void kernel_param_lock(struct module *mod)
> {
> @@ -625,9 +619,9 @@ EXPORT_SYMBOL(kernel_param_unlock);
> * create file in sysfs. Returns an error on out of memory. Always cleans up
> * if there's an error.
> */
> -static __modinit int add_sysfs_param(struct module_kobject *mk,
> - const struct kernel_param *kp,
> - const char *name)
> +static __init_or_module int add_sysfs_param(struct module_kobject *mk,
> + const struct kernel_param *kp,
> + const char *name)
> {
> struct module_param_attrs *new_mp;
> struct attribute **new_attrs;
> @@ -760,7 +754,8 @@ void destroy_params(const struct kernel_param *params, unsigned num)
> params[i].ops->free(params[i].arg);
> }
>
> -struct module_kobject __modinit * lookup_or_create_module_kobject(const char *name)
> +struct module_kobject * __init_or_module
> +lookup_or_create_module_kobject(const char *name)
> {
> struct module_kobject *mk;
> struct kobject *kobj;
>
> base-commit: be48bcf004f9d0c9207ff21d0edb3b42f253829e
> --
> 2.50.1
>
>
Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
--
Aaron Tomlin
^ permalink raw reply
* Re: [PATCH v2 10/10] module loader: enforce symbol import protection
From: kernel test robot @ 2025-10-23 9:58 UTC (permalink / raw)
To: Siddharth Nayyar, petr.pavlu
Cc: llvm, oe-kbuild-all, arnd, linux-arch, linux-kbuild, linux-kernel,
linux-modules, mcgrof, nathan, nicolas.schier, samitolvanen,
sidnayyar, maennich, gprocida
In-Reply-To: <20251013153918.2206045-11-sidnayyar@google.com>
Hi Siddharth,
kernel test robot noticed the following build errors:
[auto build test ERROR on arnd-asm-generic/master]
[also build test ERROR on soc/for-next linus/master v6.18-rc2 next-20251023]
[cannot apply to mcgrof/modules-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Siddharth-Nayyar/define-kernel-symbol-flags/20251021-104658
base: https://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git master
patch link: https://lore.kernel.org/r/20251013153918.2206045-11-sidnayyar%40google.com
patch subject: [PATCH v2 10/10] module loader: enforce symbol import protection
config: x86_64-kexec (https://download.01.org/0day-ci/archive/20251023/202510231707.zbQhQZmN-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251023/202510231707.zbQhQZmN-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202510231707.zbQhQZmN-lkp@intel.com/
All errors (new ones prefixed by >>):
>> kernel/module/main.c:1271:32: error: no member named 'sig_ok' in 'struct module'
1271 | if (fsa.is_protected && !mod->sig_ok) {
| ~~~ ^
1 error generated.
vim +1271 kernel/module/main.c
1228
1229 /* Resolve a symbol for this module. I.e. if we find one, record usage. */
1230 static const struct kernel_symbol *resolve_symbol(struct module *mod,
1231 const struct load_info *info,
1232 const char *name,
1233 char ownername[])
1234 {
1235 struct find_symbol_arg fsa = {
1236 .name = name,
1237 .gplok = !(mod->taints & (1 << TAINT_PROPRIETARY_MODULE)),
1238 .warn = true,
1239 };
1240 int err;
1241
1242 /*
1243 * The module_mutex should not be a heavily contended lock;
1244 * if we get the occasional sleep here, we'll go an extra iteration
1245 * in the wait_event_interruptible(), which is harmless.
1246 */
1247 sched_annotate_sleep();
1248 mutex_lock(&module_mutex);
1249 if (!find_symbol(&fsa))
1250 goto unlock;
1251
1252 if (fsa.license == GPL_ONLY)
1253 mod->using_gplonly_symbols = true;
1254
1255 if (!inherit_taint(mod, fsa.owner, name)) {
1256 fsa.sym = NULL;
1257 goto getname;
1258 }
1259
1260 if (!check_version(info, name, mod, fsa.crc)) {
1261 fsa.sym = ERR_PTR(-EINVAL);
1262 goto getname;
1263 }
1264
1265 err = verify_namespace_is_imported(info, fsa.sym, mod);
1266 if (err) {
1267 fsa.sym = ERR_PTR(err);
1268 goto getname;
1269 }
1270
> 1271 if (fsa.is_protected && !mod->sig_ok) {
1272 pr_warn("%s: Cannot use protected symbol %s\n",
1273 mod->name, name);
1274 fsa.sym = ERR_PTR(-EACCES);
1275 goto getname;
1276 }
1277
1278 err = ref_module(mod, fsa.owner);
1279 if (err) {
1280 fsa.sym = ERR_PTR(err);
1281 goto getname;
1282 }
1283
1284 getname:
1285 /* We must make copy under the lock if we failed to get ref. */
1286 strscpy(ownername, module_name(fsa.owner), MODULE_NAME_LEN);
1287 unlock:
1288 mutex_unlock(&module_mutex);
1289 return fsa.sym;
1290 }
1291
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [syzbot] [mm?] BUG: soft lockup in sys_bpf
From: syzbot @ 2025-10-25 15:30 UTC (permalink / raw)
To: akpm, apopple, byungchul, da.gomez, david, gourry, joshua.hahnjy,
linux-kernel, linux-mm, linux-modules, matthew.brost, mcgrof,
netdev, petr.pavlu, rakie.kim, samitolvanen, syzkaller-bugs,
ying.huang, ziy
In-Reply-To: <68087f2f.050a0220.dd94f.0177.GAE@google.com>
syzbot has found a reproducer for the following issue on:
HEAD commit: 566771afc7a8 Merge tag 'v6.18-rc2-smb-server-fixes' of git..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15c8ee7c580000
kernel config: https://syzkaller.appspot.com/x/.config?x=8345ce4ce316ca28
dashboard link: https://syzkaller.appspot.com/bug?extid=9431dc0c0741cff46a99
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=157013cd980000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=130cc7e2580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/52417ef1f782/disk-566771af.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/66730a263bf1/vmlinux-566771af.xz
kernel image: https://storage.googleapis.com/syzbot-assets/1fe0762efb1f/bzImage-566771af.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+9431dc0c0741cff46a99@syzkaller.appspotmail.com
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1): P5823
rcu: (detected by 1, t=10502 jiffies, g=8989, q=37467 ncpus=2)
task:syz-executor333 state:R running task stack:24744 pid:5823 tgid:5823 ppid:5816 task_flags:0x400140 flags:0x00080001
Call Trace:
<IRQ>
sched_show_task+0x49d/0x630 kernel/sched/core.c:7901
rcu_print_detail_task_stall_rnp kernel/rcu/tree_stall.h:292 [inline]
print_other_cpu_stall+0xf78/0x1340 kernel/rcu/tree_stall.h:681
check_cpu_stall kernel/rcu/tree_stall.h:857 [inline]
rcu_pending kernel/rcu/tree.c:3671 [inline]
rcu_sched_clock_irq+0xa47/0x11b0 kernel/rcu/tree.c:2706
update_process_times+0x235/0x2d0 kernel/time/timer.c:2473
tick_sched_handle kernel/time/tick-sched.c:276 [inline]
tick_nohz_handler+0x39a/0x520 kernel/time/tick-sched.c:297
__run_hrtimer kernel/time/hrtimer.c:1777 [inline]
__hrtimer_run_queues+0x506/0xd40 kernel/time/hrtimer.c:1841
hrtimer_interrupt+0x45d/0xa90 kernel/time/hrtimer.c:1903
local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1041 [inline]
__sysvec_apic_timer_interrupt+0x10b/0x410 arch/x86/kernel/apic/apic.c:1058
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline]
sysvec_apic_timer_interrupt+0xa1/0xc0 arch/x86/kernel/apic/apic.c:1052
</IRQ>
<TASK>
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697
RIP: 0010:instrument_atomic_read include/linux/instrumented.h:68 [inline]
RIP: 0010:_test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]
RIP: 0010:get_page_from_freelist+0x459/0x2960 mm/page_alloc.c:3824
Code: 8c 0d 00 48 8b 74 24 18 49 b8 00 00 00 00 00 fc ff df 48 8b 03 48 39 d8 0f 84 7e 07 00 00 48 8b 44 24 08 4c 8d a0 38 06 00 00 <4c> 89 e7 be 08 00 00 00 e8 ba 8e 0d 00 48 b9 00 00 00 00 00 fc ff
RSP: 0018:ffffc90004c97158 EFLAGS: 00000206
RAX: ffff88823fff8740 RBX: ffff88823fffc888 RCX: dffffc0000000000
RDX: 0000000000000001 RSI: ffff88813fffdf70 RDI: ffff88813fffdf70
RBP: 0000000000000000 R08: dffffc0000000000 R09: 1ffff11027fff7da
R10: dffffc0000000000 R11: ffffed1027fff7db R12: ffff88823fff8d78
R13: 0000000000000830 R14: ffffc90004c97448 R15: ffffc90004c9745c
__alloc_pages_slowpath+0x33b/0xe50 mm/page_alloc.c:4714
__alloc_frozen_pages_noprof+0x319/0x370 mm/page_alloc.c:5196
alloc_pages_mpol+0xd1/0x380 mm/mempolicy.c:2416
alloc_slab_page mm/slub.c:3055 [inline]
allocate_slab+0x96/0x350 mm/slub.c:3228
new_slab mm/slub.c:3282 [inline]
___slab_alloc+0xb12/0x13f0 mm/slub.c:4651
__slab_alloc+0xc6/0x1f0 mm/slub.c:4770
__slab_alloc_node mm/slub.c:4846 [inline]
slab_alloc_node mm/slub.c:5268 [inline]
kmem_cache_alloc_noprof+0xec/0x6b0 mm/slub.c:5287
skb_clone+0x212/0x3a0 net/core/skbuff.c:2050
____bpf_clone_redirect net/core/filter.c:2465 [inline]
bpf_clone_redirect+0xad/0x3d0 net/core/filter.c:2450
bpf_prog_3e1cbbed0c4acd81+0x5f/0x68
bpf_dispatcher_nop_func include/linux/bpf.h:1350 [inline]
__bpf_prog_run include/linux/filter.h:721 [inline]
bpf_prog_run include/linux/filter.h:728 [inline]
bpf_test_run+0x313/0x7a0 net/bpf/test_run.c:423
bpf_prog_test_run_skb+0xb4e/0x1550 net/bpf/test_run.c:1091
bpf_prog_test_run+0x2cd/0x340 kernel/bpf/syscall.c:4688
__sys_bpf+0x562/0x860 kernel/bpf/syscall.c:6167
__do_sys_bpf kernel/bpf/syscall.c:6259 [inline]
__se_sys_bpf kernel/bpf/syscall.c:6257 [inline]
__x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6257
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f0d40505cb9
Code: Unable to access opcode bytes at 0x7f0d40505c8f.
RSP: 002b:00007fff9d9b3ed8 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0d40505cb9
RDX: 0000000000000050 RSI: 00002000000000c0 RDI: 000000000000000a
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000006
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001
</TASK>
---
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
^ permalink raw reply
* [PATCH v2] lsm,ima: new LSM hook security_kernel_module_read_file to access decompressed kernel module
From: Coiby Xu @ 2025-10-31 7:40 UTC (permalink / raw)
To: linux-integrity, linux-security-module, Mimi Zohar
Cc: Karel Srot, Paul Moore, James Morris, Serge E. Hallyn,
Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, open list,
open list:MODULE SUPPORT
In-Reply-To: <20250928030358.3873311-1-coxu@redhat.com>
Currently, when in-kernel module decompression (CONFIG_MODULE_DECOMPRESS)
is enabled, IMA has no way to verify the appended module signature as it
can't decompress the module.
Define a new LSM hook security_kernel_module_read_file which will be
called after kernel module decompression is done so IMA can access the
decompressed kernel module to verify the appended signature.
Since IMA can access both xattr and appended kernel module signature
with the new LSM hook, it no longer uses the security_kernel_post_read_file
LSM hook for kernel module loading.
Before enabling in-kernel module decompression, a kernel module in
initramfs can still be loaded with ima_policy=secure_boot. So adjust the
kernel module rule in secure_boot policy to allow either an IMA
signature OR an appended signature i.e. to use
"appraise func=MODULE_CHECK appraise_type=imasig|modsig".
Reported-by: Karel Srot <ksrot@redhat.com>
Suggested-by: Mimi Zohar <zohar@linux.ibm.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
---
v1: https://lore.kernel.org/linux-integrity/20250928030358.3873311-1-coxu@redhat.com/
include/linux/lsm_hook_defs.h | 2 ++
include/linux/security.h | 7 +++++++
kernel/module/main.c | 10 +++++++++-
security/integrity/ima/ima_main.c | 26 ++++++++++++++++++++++++++
security/integrity/ima/ima_policy.c | 2 +-
security/security.c | 17 +++++++++++++++++
6 files changed, 62 insertions(+), 2 deletions(-)
diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
index 8c42b4bde09c..ced42eb8b618 100644
--- a/include/linux/lsm_hook_defs.h
+++ b/include/linux/lsm_hook_defs.h
@@ -232,6 +232,8 @@ LSM_HOOK(int, 0, kernel_read_file, struct file *file,
enum kernel_read_file_id id, bool contents)
LSM_HOOK(int, 0, kernel_post_read_file, struct file *file, char *buf,
loff_t size, enum kernel_read_file_id id)
+LSM_HOOK(int, 0, kernel_module_read_file, struct file *file, char *buf,
+ loff_t size)
LSM_HOOK(int, 0, task_fix_setuid, struct cred *new, const struct cred *old,
int flags)
LSM_HOOK(int, 0, task_fix_setgid, struct cred *new, const struct cred * old,
diff --git a/include/linux/security.h b/include/linux/security.h
index 92ac3f27b973..e47951292c73 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -508,6 +508,7 @@ int security_kernel_read_file(struct file *file, enum kernel_read_file_id id,
bool contents);
int security_kernel_post_read_file(struct file *file, char *buf, loff_t size,
enum kernel_read_file_id id);
+int security_kernel_module_read_file(struct file *file, char *buf, loff_t size);
int security_task_fix_setuid(struct cred *new, const struct cred *old,
int flags);
int security_task_fix_setgid(struct cred *new, const struct cred *old,
@@ -1295,6 +1296,12 @@ static inline int security_kernel_post_read_file(struct file *file,
return 0;
}
+static inline int security_kernel_module_read_file(struct file *file,
+ char *buf, loff_t size)
+{
+ return 0;
+}
+
static inline int security_task_fix_setuid(struct cred *new,
const struct cred *old,
int flags)
diff --git a/kernel/module/main.c b/kernel/module/main.c
index c66b26184936..40bc86fa7384 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -3678,6 +3678,7 @@ static int init_module_from_file(struct file *f, const char __user * uargs, int
struct load_info info = { };
void *buf = NULL;
int len;
+ int err;
len = kernel_read_file(f, 0, &buf, INT_MAX, NULL, READING_MODULE);
if (len < 0) {
@@ -3686,7 +3687,7 @@ static int init_module_from_file(struct file *f, const char __user * uargs, int
}
if (flags & MODULE_INIT_COMPRESSED_FILE) {
- int err = module_decompress(&info, buf, len);
+ err = module_decompress(&info, buf, len);
vfree(buf); /* compressed data is no longer needed */
if (err) {
mod_stat_inc(&failed_decompress);
@@ -3698,6 +3699,13 @@ static int init_module_from_file(struct file *f, const char __user * uargs, int
info.len = len;
}
+ err = security_kernel_module_read_file(f, (char *)info.hdr, info.len);
+ if (err) {
+ mod_stat_inc(&failed_kreads);
+ free_copy(&info, flags);
+ return err;
+ }
+
return load_module(&info, uargs, flags);
}
diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
index cdd225f65a62..53d2e90176ea 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -635,6 +635,27 @@ static int ima_file_check(struct file *file, int mask)
MAY_APPEND), FILE_CHECK);
}
+/**
+ * ima_read_kernel_module - collect/appraise/audit measurement
+ * @file: file pointer to the module.
+ * @buf: buffer containing module data (possibly decompressed).
+ * @size: size of the buffer.
+ *
+ * This IMA hook for kernel_module_read_file LSM hook is called after a kernel
+ * module has been read into memory and (if applicable) decompressed. It
+ * measures and/or appraises the module based on the IMA policy.
+ *
+ * Return: 0 on success, negative error code on failure.
+ */
+static int ima_read_kernel_module(struct file *file, char *buf, loff_t size)
+{
+ struct lsm_prop prop;
+
+ security_current_getlsmprop_subj(&prop);
+ return process_measurement(file, current_cred(), &prop, buf, size,
+ MAY_READ, MODULE_CHECK);
+}
+
static int __ima_inode_hash(struct inode *inode, struct file *file, char *buf,
size_t buf_size)
{
@@ -881,6 +902,10 @@ static int ima_post_read_file(struct file *file, char *buf, loff_t size,
enum ima_hooks func;
struct lsm_prop prop;
+ /* kernel module will be addressed in ima_read_kernel_module */
+ if (read_id == READING_MODULE)
+ return 0;
+
/* permit signed certs */
if (!file && read_id == READING_X509_CERTIFICATE)
return 0;
@@ -1250,6 +1275,7 @@ static struct security_hook_list ima_hooks[] __ro_after_init = {
LSM_HOOK_INIT(kernel_load_data, ima_load_data),
LSM_HOOK_INIT(kernel_post_load_data, ima_post_load_data),
LSM_HOOK_INIT(kernel_read_file, ima_read_file),
+ LSM_HOOK_INIT(kernel_module_read_file, ima_read_kernel_module),
LSM_HOOK_INIT(kernel_post_read_file, ima_post_read_file),
LSM_HOOK_INIT(path_post_mknod, ima_post_path_mknod),
#ifdef CONFIG_IMA_MEASURE_ASYMMETRIC_KEYS
diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
index 128fab897930..2c9bdc618ac9 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -241,7 +241,7 @@ static struct ima_rule_entry build_appraise_rules[] __ro_after_init = {
static struct ima_rule_entry secure_boot_rules[] __ro_after_init = {
{.action = APPRAISE, .func = MODULE_CHECK,
- .flags = IMA_FUNC | IMA_DIGSIG_REQUIRED},
+ .flags = IMA_FUNC | IMA_DIGSIG_REQUIRED | IMA_MODSIG_ALLOWED | IMA_CHECK_BLACKLIST},
{.action = APPRAISE, .func = FIRMWARE_CHECK,
.flags = IMA_FUNC | IMA_DIGSIG_REQUIRED},
{.action = APPRAISE, .func = KEXEC_KERNEL_CHECK,
diff --git a/security/security.c b/security/security.c
index 4d3c03a4524c..311ba63a8889 100644
--- a/security/security.c
+++ b/security/security.c
@@ -3442,6 +3442,23 @@ int security_kernel_post_read_file(struct file *file, char *buf, loff_t size,
}
EXPORT_SYMBOL_GPL(security_kernel_post_read_file);
+/**
+ * security_kernel_module_read_file() - Read a kernel module loaded by finit_module
+ * @file: file
+ * @buf: contents of decompressed kernel module
+ * @size: size of decompressed kernel module
+ *
+ * Read a kernel module loaded by the finit_module syscall. Unlike
+ * security_kernel_post_read_file, it has access to the decompressed kernel module.
+ *
+ * Return: Returns 0 if permission is granted.
+ */
+int security_kernel_module_read_file(struct file *file, char *buf, loff_t size)
+{
+ return call_int_hook(kernel_module_read_file, file, buf, size);
+}
+EXPORT_SYMBOL_GPL(security_kernel_module_read_file);
+
/**
* security_kernel_load_data() - Load data provided by userspace
* @id: data identifier
base-commit: e53642b87a4f4b03a8d7e5f8507fc3cd0c595ea6
--
2.51.0
^ permalink raw reply related
* [PATCH] module: Only declare set_module_sig_enforced when CONFIG_MODULE_SIG=y
From: Coiby Xu @ 2025-10-31 8:09 UTC (permalink / raw)
To: linux-modules
Cc: linux-integrity, kernel test robot, Luis Chamberlain, Petr Pavlu,
Daniel Gomez, Sami Tolvanen, open list:MODULE SUPPORT
Currently, set_module_sig_enforced is declared as long as CONFIG_MODULES
is enabled. This can lead to a linking error if
set_module_sig_enforced is called with CONFIG_MODULE_SIG=n,
ld: security/integrity/ima/ima_appraise.o: in function `ima_appraise_measurement':
security/integrity/ima/ima_appraise.c:587:(.text+0xbbb): undefined reference to `set_module_sig_enforced'
So only declare set_module_sig_enforced when CONFIG_MODULE_SIG is
enabled.
Note this issue hasn't caused a real problem because all current callers
of set_module_sig_enforced e.g. security/integrity/ima/ima_efi.c
depend on CONFIG_MODULE_SIG=y.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202510030029.VRKgik99-lkp@intel.com/
Signed-off-by: Coiby Xu <coxu@redhat.com>
---
include/linux/module.h | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index e135cc79acee..fa251958b138 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -769,8 +769,6 @@ static inline bool is_livepatch_module(struct module *mod)
#endif
}
-void set_module_sig_enforced(void);
-
void module_for_each_mod(int(*func)(struct module *mod, void *data), void *data);
#else /* !CONFIG_MODULES... */
@@ -865,10 +863,6 @@ static inline bool module_requested_async_probing(struct module *module)
}
-static inline void set_module_sig_enforced(void)
-{
-}
-
/* Dereference module function descriptor */
static inline
void *dereference_module_function_descriptor(struct module *mod, void *ptr)
@@ -924,6 +918,8 @@ static inline bool retpoline_module_ok(bool has_retpoline)
#ifdef CONFIG_MODULE_SIG
bool is_module_sig_enforced(void);
+void set_module_sig_enforced(void);
+
static inline bool module_sig_ok(struct module *module)
{
return module->sig_ok;
@@ -934,6 +930,10 @@ static inline bool is_module_sig_enforced(void)
return false;
}
+static inline void set_module_sig_enforced(void)
+{
+}
+
static inline bool module_sig_ok(struct module *module)
{
return true;
base-commit: e53642b87a4f4b03a8d7e5f8507fc3cd0c595ea6
--
2.51.0
^ permalink raw reply related
* Re: [PATCH 1/4] rust: macros: Add support for 'imports_ns' to module!
From: Miguel Ojeda @ 2025-10-31 12:57 UTC (permalink / raw)
To: Uwe Kleine-König, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen
Cc: Miguel Ojeda, Alex Gaynor, Michal Wilczynski, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Danilo Krummrich, Drew Fustini, Guo Ren,
Fu Wei, Stephen Rothwell, rust-for-linux, linux-kernel, linux-pwm,
linux-riscv, linux-modules
In-Reply-To: <h3sivr3uuzr5oodqe326svchbw3rzo4f4nw4chpeee2jwzjq3j@bdtecauehkn4>
On Fri, Oct 31, 2025 at 8:47 AM Uwe Kleine-König <ukleinek@kernel.org> wrote:
>
> I already asked this in reply to the cover letter, but the question was
> lost on the way (no offense!), so I'm asking again. As it only really
> affects this patch, I'm doing that here:
>
> Can I have some blessing to take this patch via my pwm tree? Would you
> prefer a tag to also merge it into your tree? Then I would apply it on
> top of 6.18-rc1 and provide a tag for you to merge.
Sounds fine to me, but I am Cc'ing the modules maintainers since they
were not, just in case:
Acked-by: Miguel Ojeda <ojeda@kernel.org>
I think we don't need the tag/merge, unless someone else is looking to
use this (is there such a user? I may have missed it).
Thanks!
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH 1/4] rust: macros: Add support for 'imports_ns' to module!
From: Daniel Gomez @ 2025-10-31 13:12 UTC (permalink / raw)
To: Miguel Ojeda, Uwe Kleine-König, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen
Cc: Miguel Ojeda, Alex Gaynor, Michal Wilczynski, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Danilo Krummrich, Drew Fustini, Guo Ren,
Fu Wei, Stephen Rothwell, rust-for-linux, linux-kernel, linux-pwm,
linux-riscv, linux-modules
In-Reply-To: <CANiq72nNxVJeMZdESrrB+LGmdRK+M5AGZbUw-x2aE-Qa-=HtJQ@mail.gmail.com>
On 31/10/2025 13.57, Miguel Ojeda wrote:
> On Fri, Oct 31, 2025 at 8:47 AM Uwe Kleine-König <ukleinek@kernel.org> wrote:
>>
>> I already asked this in reply to the cover letter, but the question was
>> lost on the way (no offense!), so I'm asking again. As it only really
>> affects this patch, I'm doing that here:
>>
>> Can I have some blessing to take this patch via my pwm tree? Would you
>> prefer a tag to also merge it into your tree? Then I would apply it on
>> top of 6.18-rc1 and provide a tag for you to merge.
>
> Sounds fine to me, but I am Cc'ing the modules maintainers since they
> were not, just in case:
>
> Acked-by: Miguel Ojeda <ojeda@kernel.org>
>
> I think we don't need the tag/merge, unless someone else is looking to
> use this (is there such a user? I may have missed it).
>
> Thanks!
>
> Cheers,
> Miguel
Uwe, that's okay from modules side:
Acked-by: Daniel Gomez <da.gomez@samsung.com>
FYI, I haven't merged Andreas's patches (rust: extend `module!` macro with
integer parameter support) yet, which add rust/macros/module.rs to our
MAINTAINERS file list. So, it's fine from modules side to go through your tree.
I was aiming to merge these patches along with some others for this week but
I've found a regression in kmod testing introduced in the latest v6.18-rc1,
which is taking me some extra time.
^ permalink raw reply
* Re: [PATCH] module: Only declare set_module_sig_enforced when CONFIG_MODULE_SIG=y
From: Aaron Tomlin @ 2025-10-31 20:09 UTC (permalink / raw)
To: Coiby Xu
Cc: linux-modules, linux-integrity, kernel test robot,
Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
open list:MODULE SUPPORT
In-Reply-To: <20251031080949.2001716-1-coxu@redhat.com>
On Fri, Oct 31, 2025 at 04:09:48PM +0800, Coiby Xu wrote:
> Currently, set_module_sig_enforced is declared as long as CONFIG_MODULES
> is enabled. This can lead to a linking error if
> set_module_sig_enforced is called with CONFIG_MODULE_SIG=n,
>
> ld: security/integrity/ima/ima_appraise.o: in function `ima_appraise_measurement':
> security/integrity/ima/ima_appraise.c:587:(.text+0xbbb): undefined reference to `set_module_sig_enforced'
>
> So only declare set_module_sig_enforced when CONFIG_MODULE_SIG is
> enabled.
>
> Note this issue hasn't caused a real problem because all current callers
> of set_module_sig_enforced e.g. security/integrity/ima/ima_efi.c
> depend on CONFIG_MODULE_SIG=y.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202510030029.VRKgik99-lkp@intel.com/
> Signed-off-by: Coiby Xu <coxu@redhat.com>
> ---
> include/linux/module.h | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/module.h b/include/linux/module.h
> index e135cc79acee..fa251958b138 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -769,8 +769,6 @@ static inline bool is_livepatch_module(struct module *mod)
> #endif
> }
>
> -void set_module_sig_enforced(void);
> -
> void module_for_each_mod(int(*func)(struct module *mod, void *data), void *data);
>
> #else /* !CONFIG_MODULES... */
> @@ -865,10 +863,6 @@ static inline bool module_requested_async_probing(struct module *module)
> }
>
>
> -static inline void set_module_sig_enforced(void)
> -{
> -}
> -
> /* Dereference module function descriptor */
> static inline
> void *dereference_module_function_descriptor(struct module *mod, void *ptr)
> @@ -924,6 +918,8 @@ static inline bool retpoline_module_ok(bool has_retpoline)
> #ifdef CONFIG_MODULE_SIG
> bool is_module_sig_enforced(void);
>
> +void set_module_sig_enforced(void);
> +
> static inline bool module_sig_ok(struct module *module)
> {
> return module->sig_ok;
> @@ -934,6 +930,10 @@ static inline bool is_module_sig_enforced(void)
> return false;
> }
>
> +static inline void set_module_sig_enforced(void)
> +{
> +}
> +
> static inline bool module_sig_ok(struct module *module)
> {
> return true;
>
> base-commit: e53642b87a4f4b03a8d7e5f8507fc3cd0c595ea6
> --
> 2.51.0
>
>
Looks good to me.
Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
--
Aaron Tomlin
^ permalink raw reply
* Re: [PATCH v8 04/23] slab: add sheaf support for batching kfree_rcu() operations
From: Daniel Gomez @ 2025-10-31 21:32 UTC (permalink / raw)
To: Vlastimil Babka, Suren Baghdasaryan, Liam R. Howlett,
Christoph Lameter, David Rientjes
Cc: Roman Gushchin, Harry Yoo, Uladzislau Rezki, Sidhartha Kumar,
linux-mm, linux-kernel, rcu, maple-tree, linux-modules,
Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Aaron Tomlin,
Lucas De Marchi
In-Reply-To: <20250910-slub-percpu-caches-v8-4-ca3099d8352c@suse.cz>
On 10/09/2025 10.01, Vlastimil Babka wrote:
> Extend the sheaf infrastructure for more efficient kfree_rcu() handling.
> For caches with sheaves, on each cpu maintain a rcu_free sheaf in
> addition to main and spare sheaves.
>
> kfree_rcu() operations will try to put objects on this sheaf. Once full,
> the sheaf is detached and submitted to call_rcu() with a handler that
> will try to put it in the barn, or flush to slab pages using bulk free,
> when the barn is full. Then a new empty sheaf must be obtained to put
> more objects there.
>
> It's possible that no free sheaves are available to use for a new
> rcu_free sheaf, and the allocation in kfree_rcu() context can only use
> GFP_NOWAIT and thus may fail. In that case, fall back to the existing
> kfree_rcu() implementation.
>
> Expected advantages:
> - batching the kfree_rcu() operations, that could eventually replace the
> existing batching
> - sheaves can be reused for allocations via barn instead of being
> flushed to slabs, which is more efficient
> - this includes cases where only some cpus are allowed to process rcu
> callbacks (Android)
>
> Possible disadvantage:
> - objects might be waiting for more than their grace period (it is
> determined by the last object freed into the sheaf), increasing memory
> usage - but the existing batching does that too.
>
> Only implement this for CONFIG_KVFREE_RCU_BATCHED as the tiny
> implementation favors smaller memory footprint over performance.
>
> Also for now skip the usage of rcu sheaf for CONFIG_PREEMPT_RT as the
> contexts where kfree_rcu() is called might not be compatible with taking
> a barn spinlock or a GFP_NOWAIT allocation of a new sheaf taking a
> spinlock - the current kfree_rcu() implementation avoids doing that.
>
> Teach kvfree_rcu_barrier() to flush all rcu_free sheaves from all caches
> that have them. This is not a cheap operation, but the barrier usage is
> rare - currently kmem_cache_destroy() or on module unload.
>
> Add CONFIG_SLUB_STATS counters free_rcu_sheaf and free_rcu_sheaf_fail to
> count how many kfree_rcu() used the rcu_free sheaf successfully and how
> many had to fall back to the existing implementation.
>
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Hi Vlastimil,
This patch increases kmod selftest (stress module loader) runtime by about
~50-60%, from ~200s to ~300s total execution time. My tested kernel has
CONFIG_KVFREE_RCU_BATCHED enabled. Any idea or suggestions on what might be
causing this, or how to address it?
^ permalink raw reply
* Re: [PATCH 1/4] rust: macros: Add support for 'imports_ns' to module!
From: Uwe Kleine-König @ 2025-11-01 8:06 UTC (permalink / raw)
To: Daniel Gomez, Miguel Ojeda
Cc: Luis Chamberlain, Petr Pavlu, Sami Tolvanen, Miguel Ojeda,
Alex Gaynor, Michal Wilczynski, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Drew Fustini, Guo Ren, Fu Wei,
Stephen Rothwell, rust-for-linux, linux-kernel, linux-pwm,
linux-riscv, linux-modules
In-Reply-To: <4654398f-324c-4465-88eb-8cadde6160dc@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1795 bytes --]
Hello Daniel, hello Miguel,
On Fri, Oct 31, 2025 at 02:12:29PM +0100, Daniel Gomez wrote:
> On 31/10/2025 13.57, Miguel Ojeda wrote:
> > On Fri, Oct 31, 2025 at 8:47 AM Uwe Kleine-König <ukleinek@kernel.org> wrote:
> > > Can I have some blessing to take this patch via my pwm tree? Would you
> > > prefer a tag to also merge it into your tree? Then I would apply it on
> > > top of 6.18-rc1 and provide a tag for you to merge.
> >
> > Sounds fine to me, but I am Cc'ing the modules maintainers since they
> > were not, just in case:
Good idea, thanks for catching that.
> > Acked-by: Miguel Ojeda <ojeda@kernel.org>
> > [...]
>
> Uwe, that's okay from modules side:
>
> Acked-by: Daniel Gomez <da.gomez@samsung.com>
Thanks for your Acks, I applied patches #1-#3 to
https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git pwm/for-next
(#4 was applied already).
> FYI, I haven't merged Andreas's patches (rust: extend `module!` macro with
> integer parameter support) yet, which add rust/macros/module.rs to our
> MAINTAINERS file list. So, it's fine from modules side to go through your tree.
> I was aiming to merge these patches along with some others for this week but
> I've found a regression in kmod testing introduced in the latest v6.18-rc1,
> which is taking me some extra time.
If the issues you mentioned are sorted out and you apply patches that
conflict with the changes I committed, please get in touch that we
coordinate if/how to sort them out.
Also if the need for a tag to share the commit arises, please coordinate
and don't just merge the just now created commits, as I like to be able
to rewrite my tree for late Acks etc. So I'd like to prepare and know
when commits become set in stone.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2] lsm,ima: new LSM hook security_kernel_module_read_file to access decompressed kernel module
From: Paul Moore @ 2025-11-01 16:50 UTC (permalink / raw)
To: Coiby Xu
Cc: linux-integrity, linux-security-module, Mimi Zohar, Karel Srot,
James Morris, Serge E. Hallyn, Luis Chamberlain, Petr Pavlu,
Daniel Gomez, Sami Tolvanen, Roberto Sassu, Dmitry Kasatkin,
Eric Snowberg, open list, open list:MODULE SUPPORT
In-Reply-To: <20251031074016.1975356-1-coxu@redhat.com>
On Fri, Oct 31, 2025 at 3:41 AM Coiby Xu <coxu@redhat.com> wrote:
>
> Currently, when in-kernel module decompression (CONFIG_MODULE_DECOMPRESS)
> is enabled, IMA has no way to verify the appended module signature as it
> can't decompress the module.
>
> Define a new LSM hook security_kernel_module_read_file which will be
> called after kernel module decompression is done so IMA can access the
> decompressed kernel module to verify the appended signature.
>
> Since IMA can access both xattr and appended kernel module signature
> with the new LSM hook, it no longer uses the security_kernel_post_read_file
> LSM hook for kernel module loading.
>
> Before enabling in-kernel module decompression, a kernel module in
> initramfs can still be loaded with ima_policy=secure_boot. So adjust the
> kernel module rule in secure_boot policy to allow either an IMA
> signature OR an appended signature i.e. to use
> "appraise func=MODULE_CHECK appraise_type=imasig|modsig".
>
> Reported-by: Karel Srot <ksrot@redhat.com>
> Suggested-by: Mimi Zohar <zohar@linux.ibm.com>
> Signed-off-by: Coiby Xu <coxu@redhat.com>
> ---
> v1: https://lore.kernel.org/linux-integrity/20250928030358.3873311-1-coxu@redhat.com/
>
> include/linux/lsm_hook_defs.h | 2 ++
> include/linux/security.h | 7 +++++++
> kernel/module/main.c | 10 +++++++++-
> security/integrity/ima/ima_main.c | 26 ++++++++++++++++++++++++++
> security/integrity/ima/ima_policy.c | 2 +-
> security/security.c | 17 +++++++++++++++++
> 6 files changed, 62 insertions(+), 2 deletions(-)
We don't really need a new LSM hook for this do we? Can't we just
define a new file read type, e.g. READING_MODULE_DECOMPRESS, and do
another call to security_kernel_post_read_file() after the module is
unpacked? Something like the snippet below ...
diff --git a/kernel/module/main.c b/kernel/module/main.c
index c66b26184936..f127000d2e0a 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -3693,6 +3693,14 @@ static int init_module_from_file(struct file *f, const ch
ar __user * uargs, int
mod_stat_add_long(len, &invalid_decompress_bytes);
return err;
}
+
+ err = security_kernel_post_read_file(f,
+ (char *)info.hdr, info.len,
+ READING_MODULE_DECOMPRESS);
+ if (err) {
+ mod_stat_inc(&failed_kreads);
+ return err;
+ }
} else {
info.hdr = buf;
info.len = len;
--
paul-moore.com
^ permalink raw reply related
* Re: [PATCH v18 0/7] rust: extend `module!` macro with integer parameter support
From: Daniel Gomez @ 2025-11-01 21:39 UTC (permalink / raw)
To: Andreas Hindborg, Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
Björn Roy Baron, Alice Ryhl, Masahiro Yamada,
Nathan Chancellor, Luis Chamberlain, Danilo Krummrich,
Benno Lossin, Nicolas Schier, Uwe Kleine-König,
Michal Wilczynski
Cc: Trevor Gross, Adam Bratschi-Kaye, rust-for-linux, linux-kernel,
linux-kbuild, Petr Pavlu, Sami Tolvanen, Daniel Gomez,
Simona Vetter, Greg KH, Fiona Behrens, Daniel Almeida,
linux-modules
In-Reply-To: <20250924-module-params-v3-v18-0-bf512c35d910@kernel.org>
On 24/09/2025 14.39, Andreas Hindborg wrote:
> Extend the `module!` macro with support module parameters. Also add some
> string to integer parsing functions.
>
> Based on the original module parameter support by Miguel [1],
> later extended and generalized by Adam for more types [2][3].
> Originally tracked at [4].
>
> Link: https://github.com/Rust-for-Linux/linux/pull/7 [1]
> Link: https://github.com/Rust-for-Linux/linux/pull/82 [2]
> Link: https://github.com/Rust-for-Linux/linux/pull/87 [3]
> Link: https://github.com/Rust-for-Linux/linux/issues/11 [4]
> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
I tested this series with rust_minimal module. They LGTM,
Tested-by: Daniel Gomez <da.gomez@samsung.com>
The patches did not apply cleanly to v6.18-rc3, at least not when using b4.
However, when applying them to the base commit and then rebasing onto v6.18-rc3,
I didn't see any conflicts.
I've created a temporary branch with this rebase here:
https://git.kernel.org/pub/scm/linux/kernel/git/modules/linux.git/log/?h=rebase/20250924-module-params-v3-v18-0-bf512c35d910@kernel.org
Can you take a look when you can? I'll merge this shortly after checking with
Uwe, as there are some minor conflicts with his tree.
+ Uwe
These are the conflicts I see when merging the patch series from Michal [1]
(Introduce import_ns support for Rust). I believe these are trivial things that
we will get notified from linux-next merging. But let me know what you think as
you have requested in that thread.
[1] Link: https://lore.kernel.org/all/20251028-pwm_fixes-v1-0-25a532d31998@samsung.com/
...
Applying: rust: macros: Add support for 'imports_ns' to module!
Patch failed at 0008 rust: macros: Add support for 'imports_ns' to module!
error: patch failed: rust/macros/module.rs:98
error: rust/macros/module.rs: patch does not apply
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
git am --show-current-patch=diff
---
rust/macros/module.rs | 8 ++++++++
1 file changed, 8 insertions(+)
---
rust/macros/module.rs | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/rust/macros/module.rs b/rust/macros/module.rs
index 5ee54a00c0b65699596e660b2d4d60e64be2a50c..408cd115487514c8be79724d901c676435696376 100644
--- a/rust/macros/module.rs
+++ b/rust/macros/module.rs
@@ -98,6 +98,7 @@ struct ModuleInfo {
description: Option<String>,
alias: Option<Vec<String>>,
firmware: Option<Vec<String>>,
+ imports_ns: Option<Vec<String>>,
}
impl ModuleInfo {
@@ -112,6 +113,7 @@ fn parse(it: &mut token_stream::IntoIter) -> Self {
"license",
"alias",
"firmware",
+ "imports_ns",
];
const REQUIRED_KEYS: &[&str] = &["type", "name", "license"];
let mut seen_keys = Vec::new();
@@ -137,6 +139,7 @@ fn parse(it: &mut token_stream::IntoIter) -> Self {
"license" => info.license = expect_string_ascii(it),
"alias" => info.alias = Some(expect_string_array(it)),
"firmware" => info.firmware = Some(expect_string_array(it)),
+ "imports_ns" => info.imports_ns = Some(expect_string_array(it)),
_ => panic!("Unknown key \"{key}\". Valid keys are: {EXPECTED_KEYS:?}."),
}
@@ -195,6 +198,11 @@ pub(crate) fn module(ts: TokenStream) -> TokenStream {
modinfo.emit("firmware", &fw);
}
}
+ if let Some(imports) = info.imports_ns {
+ for ns in imports {
+ modinfo.emit("import_ns", &ns);
+ }
+ }
// Built-in modules also export the `file` modinfo string.
let file =
^ permalink raw reply related
* Re: [PATCH] module: Only declare set_module_sig_enforced when CONFIG_MODULE_SIG=y
From: Daniel Gomez @ 2025-11-01 22:10 UTC (permalink / raw)
To: Coiby Xu, linux-modules
Cc: linux-integrity, kernel test robot, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen, open list:MODULE SUPPORT
In-Reply-To: <20251031080949.2001716-1-coxu@redhat.com>
On 31/10/2025 09.09, Coiby Xu wrote:
> Currently, set_module_sig_enforced is declared as long as CONFIG_MODULES
> is enabled. This can lead to a linking error if
> set_module_sig_enforced is called with CONFIG_MODULE_SIG=n,
>
> ld: security/integrity/ima/ima_appraise.o: in function `ima_appraise_measurement':
> security/integrity/ima/ima_appraise.c:587:(.text+0xbbb): undefined reference to `set_module_sig_enforced'
It's a bit unclear whether you're referring to a current upstream issue (which I
couldn't find as of -rc3), or if this is just a hypothetical scenario.
>
> So only declare set_module_sig_enforced when CONFIG_MODULE_SIG is
> enabled.
I only see cases where code has a safeguard like in
security/integrity/ima/ima_efi.c:71
if (IS_ENABLED(CONFIG_MODULE_SIG))
set_module_sig_enforced();
>
> Note this issue hasn't caused a real problem because all current callers
> of set_module_sig_enforced e.g. security/integrity/ima/ima_efi.c
> depend on CONFIG_MODULE_SIG=y.
I think the correct term we should use here is runtime safeguard. The code does
not actually depend on that config, nor is there any dep in Kconfig.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202510030029.VRKgik99-lkp@intel.com/
> Signed-off-by: Coiby Xu <coxu@redhat.com>
Just minor nits regarding the commit message structure. This change should allow
us to remove the safeguard from users of set_module_sig_enforced().
Other than that, LGTM,
Reviewed-by: Daniel Gomez <da.gomez@samsung.com>
^ permalink raw reply
* [PATCH] docs: ABI: sysfs-module: update modules taint flags
From: Randy Dunlap @ 2025-11-02 6:04 UTC (permalink / raw)
To: linux-kernel
Cc: Randy Dunlap, Petr Pavlu, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Luis Chamberlain, Daniel Gomez, Sami Tolvanen,
linux-modules
Add missing taint flags for loadable modules, as pointed out by
Petr Pavlu [1].
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
[1] https://lore.kernel.org/all/c58152f1-0fbe-4f50-bb61-e2f4c0584025@suse.com/
---
Cc: Petr Pavlu <petr.pavlu@suse.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: Daniel Gomez <da.gomez@kernel.org>
Cc: Sami Tolvanen <samitolvanen@google.com>
Cc: linux-modules@vger.kernel.org
---
Documentation/ABI/testing/sysfs-module | 2 ++
1 file changed, 2 insertions(+)
--- linux-next-20251031.orig/Documentation/ABI/testing/sysfs-module
+++ linux-next-20251031/Documentation/ABI/testing/sysfs-module
@@ -59,6 +59,8 @@ Description: Module taint flags:
F force-loaded module
C staging driver module
E unsigned module
+ K livepatch module
+ N in-kernel test module
== =====================
What: /sys/module/grant_table/parameters/free_per_iteration
^ permalink raw reply
* Re: [PATCH v18 0/7] rust: extend `module!` macro with integer parameter support
From: Uwe Kleine-König @ 2025-11-02 9:56 UTC (permalink / raw)
To: Daniel Gomez
Cc: Andreas Hindborg, Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
Björn Roy Baron, Alice Ryhl, Masahiro Yamada,
Nathan Chancellor, Luis Chamberlain, Danilo Krummrich,
Benno Lossin, Nicolas Schier, Michal Wilczynski, Trevor Gross,
Adam Bratschi-Kaye, rust-for-linux, linux-kernel, linux-kbuild,
Petr Pavlu, Sami Tolvanen, Daniel Gomez, Simona Vetter, Greg KH,
Fiona Behrens, Daniel Almeida, linux-modules, Stephen Rothwell,
linux-next
In-Reply-To: <49af6d76-bcb7-4343-8903-390040e2c49b@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 8479 bytes --]
Hello Daniel,
[Adding Stephen and linux-next to Cc]
On Sat, Nov 01, 2025 at 10:39:08PM +0100, Daniel Gomez wrote:
> On 24/09/2025 14.39, Andreas Hindborg wrote:
> > Extend the `module!` macro with support module parameters. Also add some
> > string to integer parsing functions.
> >
> > Based on the original module parameter support by Miguel [1],
> > later extended and generalized by Adam for more types [2][3].
> > Originally tracked at [4].
> >
> > Link: https://github.com/Rust-for-Linux/linux/pull/7 [1]
> > Link: https://github.com/Rust-for-Linux/linux/pull/82 [2]
> > Link: https://github.com/Rust-for-Linux/linux/pull/87 [3]
> > Link: https://github.com/Rust-for-Linux/linux/issues/11 [4]
> > Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
>
> I tested this series with rust_minimal module. They LGTM,
>
> Tested-by: Daniel Gomez <da.gomez@samsung.com>
>
> The patches did not apply cleanly to v6.18-rc3, at least not when using b4.
> However, when applying them to the base commit and then rebasing onto v6.18-rc3,
> I didn't see any conflicts.
I don't know how you use b4, but
git checkout v6.18-rc3
b4 am -3 49af6d76-bcb7-4343-8903-390040e2c49b@kernel.org
git am -3 ./v18_20250924_a_hindborg_rust_extend_module_macro_with_integer_parameter_support.mbx
works fine on my end. Using `-3` should have the same effect as applying
the series on top of the original base and rebase it.
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/modules/linux.git rebase/20250924-module-params-v3-v18-0-bf512c35d910@kernel.org
git range-diff FETCH_HEAD...HEAD
confirms that.
> I've created a temporary branch with this rebase here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/modules/linux.git/log/?h=rebase/20250924-module-params-v3-v18-0-bf512c35d910@kernel.org
>
> Can you take a look when you can? I'll merge this shortly after checking with
> Uwe, as there are some minor conflicts with his tree.
>
> + Uwe
>
> These are the conflicts I see when merging the patch series from Michal [1]
> (Introduce import_ns support for Rust). I believe these are trivial things that
> we will get notified from linux-next merging. But let me know what you think as
> you have requested in that thread.
>
> [1] Link: https://lore.kernel.org/all/20251028-pwm_fixes-v1-0-25a532d31998@samsung.com/
Yeah, I expect that Stephen will highlight the conflicts, but I prefer
to not be surprised by that and consider linux-next more a fallback
security net that I don't want to use. I like it to be the other way
round and tell Stephen about conflicts to expect :-)
> ...
> Applying: rust: macros: Add support for 'imports_ns' to module!
> Patch failed at 0008 rust: macros: Add support for 'imports_ns' to module!
> error: patch failed: rust/macros/module.rs:98
> error: rust/macros/module.rs: patch does not apply
> hint: Use 'git am --show-current-patch=diff' to see the failed patch
> hint: When you have resolved this problem, run "git am --continue".
> hint: If you prefer to skip this patch, run "git am --skip" instead.
> hint: To restore the original branch and stop patching, run "git am --abort".
> hint: Disable this message with "git config set advice.mergeConflict false"
>
> git am --show-current-patch=diff
That command shows the patch to apply, but not the conflict, let alone
your resolution.
> ---
> rust/macros/module.rs | 8 ++++++++
> 1 file changed, 8 insertions(+)
> ---
> rust/macros/module.rs | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/rust/macros/module.rs b/rust/macros/module.rs
> index 5ee54a00c0b65699596e660b2d4d60e64be2a50c..408cd115487514c8be79724d901c676435696376 100644
> --- a/rust/macros/module.rs
> +++ b/rust/macros/module.rs
> @@ -98,6 +98,7 @@ struct ModuleInfo {
> description: Option<String>,
> alias: Option<Vec<String>>,
> firmware: Option<Vec<String>>,
> + imports_ns: Option<Vec<String>>,
> }
So here the addition of `params` is missing.
> [...]
When I merge your branch mentioned above with my pwm/for-next and
resolve the merge conflicts, the resolution looks as follows. The only
non-trivial thing is that
if let Some(imports) = info.imports_ns {
now needs a & for `info`.
Best regards
Uwe
diff --cc rust/macros/module.rs
index d62e9c1e2a89,408cd1154875..000000000000
--- a/rust/macros/module.rs
+++ b/rust/macros/module.rs
@@@ -205,50 -98,7 +205,51 @@@ struct ModuleInfo
description: Option<String>,
alias: Option<Vec<String>>,
firmware: Option<Vec<String>>,
+ imports_ns: Option<Vec<String>>,
+ params: Option<Vec<Parameter>>,
+}
+
+#[derive(Debug)]
+struct Parameter {
+ name: String,
+ ptype: String,
+ default: String,
+ description: String,
+}
+
+fn expect_params(it: &mut token_stream::IntoIter) -> Vec<Parameter> {
+ let params = expect_group(it);
+ assert_eq!(params.delimiter(), Delimiter::Brace);
+ let mut it = params.stream().into_iter();
+ let mut parsed = Vec::new();
+
+ loop {
+ let param_name = match it.next() {
+ Some(TokenTree::Ident(ident)) => ident.to_string(),
+ Some(_) => panic!("Expected Ident or end"),
+ None => break,
+ };
+
+ assert_eq!(expect_punct(&mut it), ':');
+ let param_type = expect_ident(&mut it);
+ let group = expect_group(&mut it);
+ assert_eq!(group.delimiter(), Delimiter::Brace);
+ assert_eq!(expect_punct(&mut it), ',');
+
+ let mut param_it = group.stream().into_iter();
+ let param_default = expect_param_default(&mut param_it);
+ let param_description = expect_string_field(&mut param_it, "description");
+ expect_end(&mut param_it);
+
+ parsed.push(Parameter {
+ name: param_name,
+ ptype: param_type,
+ default: param_default,
+ description: param_description,
+ })
+ }
+
+ parsed
}
impl ModuleInfo {
@@@ -263,7 -113,7 +264,8 @@@
"license",
"alias",
"firmware",
+ "imports_ns",
+ "params",
];
const REQUIRED_KEYS: &[&str] = &["type", "name", "license"];
let mut seen_keys = Vec::new();
@@@ -289,7 -139,7 +291,8 @@@
"license" => info.license = expect_string_ascii(it),
"alias" => info.alias = Some(expect_string_array(it)),
"firmware" => info.firmware = Some(expect_string_array(it)),
+ "imports_ns" => info.imports_ns = Some(expect_string_array(it)),
+ "params" => info.params = Some(expect_params(it)),
_ => panic!("Unknown key \"{key}\". Valid keys are: {EXPECTED_KEYS:?}."),
}
@@@ -329,25 -179,30 +332,30 @@@ pub(crate) fn module(ts: TokenStream) -
// Rust does not allow hyphens in identifiers, use underscore instead.
let ident = info.name.replace('-', "_");
let mut modinfo = ModInfoBuilder::new(ident.as_ref());
- if let Some(authors) = info.authors {
+ if let Some(authors) = &info.authors {
for author in authors {
- modinfo.emit("author", &author);
+ modinfo.emit("author", author);
}
}
- if let Some(description) = info.description {
- modinfo.emit("description", &description);
+ if let Some(description) = &info.description {
+ modinfo.emit("description", description);
}
modinfo.emit("license", &info.license);
- if let Some(aliases) = info.alias {
+ if let Some(aliases) = &info.alias {
for alias in aliases {
- modinfo.emit("alias", &alias);
+ modinfo.emit("alias", alias);
}
}
- if let Some(firmware) = info.firmware {
+ if let Some(firmware) = &info.firmware {
for fw in firmware {
- modinfo.emit("firmware", &fw);
+ modinfo.emit("firmware", fw);
}
}
- if let Some(imports) = info.imports_ns {
++ if let Some(imports) = &info.imports_ns {
+ for ns in imports {
+ modinfo.emit("import_ns", &ns);
+ }
+ }
// Built-in modules also export the `file` modinfo string.
let file =
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2] lsm,ima: new LSM hook security_kernel_module_read_file to access decompressed kernel module
From: Mimi Zohar @ 2025-11-02 15:05 UTC (permalink / raw)
To: Paul Moore, Coiby Xu
Cc: linux-integrity, linux-security-module, Karel Srot, James Morris,
Serge E. Hallyn, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Roberto Sassu, Dmitry Kasatkin, Eric Snowberg,
open list, open list:MODULE SUPPORT
In-Reply-To: <CAHC9VhRBXkW+XuqhxJvEOYR_VMxFh4TRWUtXzZky=AG_nyBYEQ@mail.gmail.com>
On Sat, 2025-11-01 at 12:50 -0400, Paul Moore wrote:
> On Fri, Oct 31, 2025 at 3:41 AM Coiby Xu <coxu@redhat.com> wrote:
> >
> > Currently, when in-kernel module decompression (CONFIG_MODULE_DECOMPRESS)
> > is enabled, IMA has no way to verify the appended module signature as it
> > can't decompress the module.
> >
> > Define a new LSM hook security_kernel_module_read_file which will be
> > called after kernel module decompression is done so IMA can access the
> > decompressed kernel module to verify the appended signature.
> >
> > Since IMA can access both xattr and appended kernel module signature
> > with the new LSM hook, it no longer uses the security_kernel_post_read_file
> > LSM hook for kernel module loading.
> >
> > Before enabling in-kernel module decompression, a kernel module in
> > initramfs can still be loaded with ima_policy=secure_boot. So adjust the
> > kernel module rule in secure_boot policy to allow either an IMA
> > signature OR an appended signature i.e. to use
> > "appraise func=MODULE_CHECK appraise_type=imasig|modsig".
> >
> > Reported-by: Karel Srot <ksrot@redhat.com>
> > Suggested-by: Mimi Zohar <zohar@linux.ibm.com>
> > Signed-off-by: Coiby Xu <coxu@redhat.com>
> > ---
> > v1: https://lore.kernel.org/linux-integrity/20250928030358.3873311-1-coxu@redhat.com/
> >
> > include/linux/lsm_hook_defs.h | 2 ++
> > include/linux/security.h | 7 +++++++
> > kernel/module/main.c | 10 +++++++++-
> > security/integrity/ima/ima_main.c | 26 ++++++++++++++++++++++++++
> > security/integrity/ima/ima_policy.c | 2 +-
> > security/security.c | 17 +++++++++++++++++
> > 6 files changed, 62 insertions(+), 2 deletions(-)
>
> We don't really need a new LSM hook for this do we? Can't we just
> define a new file read type, e.g. READING_MODULE_DECOMPRESS, and do
> another call to security_kernel_post_read_file() after the module is
> unpacked? Something like the snippet below ...
Yes, this is similar to my suggestion based on defining multiple enumerations:
READING_MODULE, READING_COMPRESSED_MODULE, and READING_DECOMPRESSED_MODULE.
With this solution, IMA would need to make an exception in the post kernel
module read for the READING_COMPRESSED_MODULE case, since the kernel module has
not yet been decompressed.
Coiby suggested further simplification by moving the call later. At which point
either there is or isn't an appended signature for non-compressed and
decompressed kernel modules.
As long as you don't have a problem calling the security_kernel_post_read_file()
hook again, could we move the call later and pass READING_MODULE_UNCOMPRESSED?
>
> diff --git a/kernel/module/main.c b/kernel/module/main.c
> index c66b26184936..f127000d2e0a 100644
> --- a/kernel/module/main.c
> +++ b/kernel/module/main.c
> @@ -3693,6 +3693,14 @@ static int init_module_from_file(struct file *f, const ch
> ar __user * uargs, int
> mod_stat_add_long(len, &invalid_decompress_bytes);
> return err;
> }
> +
> + err = security_kernel_post_read_file(f,
> + (char *)info.hdr, info.len,
> + READING_MODULE_DECOMPRESS);
> + if (err) {
> + mod_stat_inc(&failed_kreads);
> + return err;
> + }
> } else {
> info.hdr = buf;
> info.len = len;
== defer security_kernel_post_read_file() call to here ==
Mimi
^ permalink raw reply
* Re: [PATCH v2] lsm,ima: new LSM hook security_kernel_module_read_file to access decompressed kernel module
From: Paul Moore @ 2025-11-02 15:43 UTC (permalink / raw)
To: Mimi Zohar
Cc: Coiby Xu, linux-integrity, linux-security-module, Karel Srot,
James Morris, Serge E. Hallyn, Luis Chamberlain, Petr Pavlu,
Daniel Gomez, Sami Tolvanen, Roberto Sassu, Dmitry Kasatkin,
Eric Snowberg, open list, open list:MODULE SUPPORT
In-Reply-To: <baa39fcd1b6b485f14b8f06dcd96b81359e6e491.camel@linux.ibm.com>
On Sun, Nov 2, 2025 at 10:06 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> On Sat, 2025-11-01 at 12:50 -0400, Paul Moore wrote:
> > On Fri, Oct 31, 2025 at 3:41 AM Coiby Xu <coxu@redhat.com> wrote:
> > >
> > > Currently, when in-kernel module decompression (CONFIG_MODULE_DECOMPRESS)
> > > is enabled, IMA has no way to verify the appended module signature as it
> > > can't decompress the module.
> > >
> > > Define a new LSM hook security_kernel_module_read_file which will be
> > > called after kernel module decompression is done so IMA can access the
> > > decompressed kernel module to verify the appended signature.
> > >
> > > Since IMA can access both xattr and appended kernel module signature
> > > with the new LSM hook, it no longer uses the security_kernel_post_read_file
> > > LSM hook for kernel module loading.
> > >
> > > Before enabling in-kernel module decompression, a kernel module in
> > > initramfs can still be loaded with ima_policy=secure_boot. So adjust the
> > > kernel module rule in secure_boot policy to allow either an IMA
> > > signature OR an appended signature i.e. to use
> > > "appraise func=MODULE_CHECK appraise_type=imasig|modsig".
> > >
> > > Reported-by: Karel Srot <ksrot@redhat.com>
> > > Suggested-by: Mimi Zohar <zohar@linux.ibm.com>
> > > Signed-off-by: Coiby Xu <coxu@redhat.com>
> > > ---
> > > v1: https://lore.kernel.org/linux-integrity/20250928030358.3873311-1-coxu@redhat.com/
> > >
> > > include/linux/lsm_hook_defs.h | 2 ++
> > > include/linux/security.h | 7 +++++++
> > > kernel/module/main.c | 10 +++++++++-
> > > security/integrity/ima/ima_main.c | 26 ++++++++++++++++++++++++++
> > > security/integrity/ima/ima_policy.c | 2 +-
> > > security/security.c | 17 +++++++++++++++++
> > > 6 files changed, 62 insertions(+), 2 deletions(-)
> >
> > We don't really need a new LSM hook for this do we? Can't we just
> > define a new file read type, e.g. READING_MODULE_DECOMPRESS, and do
> > another call to security_kernel_post_read_file() after the module is
> > unpacked? Something like the snippet below ...
>
> Yes, this is similar to my suggestion based on defining multiple enumerations:
> READING_MODULE, READING_COMPRESSED_MODULE, and READING_DECOMPRESSED_MODULE.
> With this solution, IMA would need to make an exception in the post kernel
> module read for the READING_COMPRESSED_MODULE case, since the kernel module has
> not yet been decompressed.
>
> Coiby suggested further simplification by moving the call later. At which point
> either there is or isn't an appended signature for non-compressed and
> decompressed kernel modules.
>
> As long as you don't have a problem calling the security_kernel_post_read_file()
> hook again, could we move the call later and pass READING_MODULE_UNCOMPRESSED?
It isn't clear from these comments if you are talking about moving
only the second security_kernel_post_read_file() call that was
proposed for init_module_from_file() to later in the function, leaving
the call in kernel_read_file() intact, or something else?
I think we want to leave the hook calls in kernel_read_file() intact,
in which case I'm not certain what advantage there is in moving the
security_kernel_post_read_file() call to a location where it is called
in init_module_from_file() regardless of if the module is compressed
or not. In the uncompressed case you are calling the hook twice for
no real benefit? It may be helpful to submit a patch with your
proposal as a patch can be worth a thousand words ;)
> > diff --git a/kernel/module/main.c b/kernel/module/main.c
> > index c66b26184936..f127000d2e0a 100644
> > --- a/kernel/module/main.c
> > +++ b/kernel/module/main.c
> > @@ -3693,6 +3693,14 @@ static int init_module_from_file(struct file *f, const ch
> > ar __user * uargs, int
> > mod_stat_add_long(len, &invalid_decompress_bytes);
> > return err;
> > }
> > +
> > + err = security_kernel_post_read_file(f,
> > + (char *)info.hdr, info.len,
> > + READING_MODULE_DECOMPRESS);
> > + if (err) {
> > + mod_stat_inc(&failed_kreads);
> > + return err;
> > + }
> > } else {
> > info.hdr = buf;
> > info.len = len;
>
> == defer security_kernel_post_read_file() call to here ==
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH 2/2] module: Simplify warning on positive returns from module_init()
From: Aaron Tomlin @ 2025-11-02 18:23 UTC (permalink / raw)
To: Lucas De Marchi; +Cc: linux-modules, linux-kernel, Petr Pavlu
In-Reply-To: <20251013-module-warn-ret-v1-2-ab65b41af01f@intel.com>
On Mon, Oct 13, 2025 at 09:26:24AM -0700, Lucas De Marchi wrote:
> It should now be rare to trigger this warning - it doesn't need to be so
> verbose. Make it follow the usual style in the module loading code.
>
> For the same reason, drop the dump_stack().
>
> Suggested-by: Petr Pavlu <petr.pavlu@suse.com>
> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> ---
> kernel/module/main.c | 10 +++-------
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/kernel/module/main.c b/kernel/module/main.c
> index 74ff87b13c517..31c54bf6df4b2 100644
> --- a/kernel/module/main.c
> +++ b/kernel/module/main.c
> @@ -3045,13 +3045,9 @@ static noinline int do_init_module(struct module *mod)
> }
> goto fail_free_freeinit;
> }
> - if (ret > 0) {
> - pr_warn("%s: '%s'->init suspiciously returned %d, it should "
> - "follow 0/-E convention\n"
> - "%s: loading module anyway...\n",
> - __func__, mod->name, ret, __func__);
> - dump_stack();
> - }
> + if (ret > 0)
> + pr_warn("%s: init suspiciously returned %d, it should follow 0/-E convention\n",
> + mod->name, ret);
>
> /* Now it's a first class citizen! */
> mod->state = MODULE_STATE_LIVE;
>
> --
> 2.51.0
>
>
Fair enough. Looks good to me.
Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
--
Aaron Tomlin
^ permalink raw reply
* Re: [PATCH 1/2] module: Override -EEXISTS module return
From: Aaron Tomlin @ 2025-11-02 18:23 UTC (permalink / raw)
To: Lucas De Marchi; +Cc: linux-modules, linux-kernel, Petr Pavlu
In-Reply-To: <20251013-module-warn-ret-v1-1-ab65b41af01f@intel.com>
On Mon, Oct 13, 2025 at 09:26:23AM -0700, Lucas De Marchi wrote:
> The -EEXIST errno is reserved by the module loading functionality. When
> userspace calls [f]init_module(), it expects a -EEXIST to mean that the
> module is already loaded in the kernel. If module_init() returns it,
> that is not true anymore.
>
> Add a warning and override the return code to workaround modules
> currently returning the wrong code. It's expected that they eventually
> migrate to a better suited error.
>
> Closes: https://lore.kernel.org/all/aKLzsAX14ybEjHfJ@orbyte.nwl.cc/
> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
> ---
> kernel/module/main.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/kernel/module/main.c b/kernel/module/main.c
> index c66b261849362..74ff87b13c517 100644
> --- a/kernel/module/main.c
> +++ b/kernel/module/main.c
> @@ -3038,6 +3038,11 @@ static noinline int do_init_module(struct module *mod)
> if (mod->init != NULL)
> ret = do_one_initcall(mod->init);
> if (ret < 0) {
> + if (ret == -EEXIST) {
> + pr_warn("%s: init suspiciously returned -EEXIST: Overriding with -EBUSY\n",
> + mod->name);
> + ret = -EBUSY;
> + }
> goto fail_free_freeinit;
> }
> if (ret > 0) {
>
> --
> 2.51.0
>
>
Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
--
Aaron Tomlin
^ permalink raw reply
* Re: [PATCH v18 0/7] rust: extend `module!` macro with integer parameter support
From: Daniel Gomez @ 2025-11-02 21:19 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Andreas Hindborg, Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
Björn Roy Baron, Alice Ryhl, Masahiro Yamada,
Nathan Chancellor, Luis Chamberlain, Danilo Krummrich,
Benno Lossin, Nicolas Schier, Michal Wilczynski, Trevor Gross,
Adam Bratschi-Kaye, rust-for-linux, linux-kernel, linux-kbuild,
Petr Pavlu, Sami Tolvanen, Daniel Gomez, Simona Vetter, Greg KH,
Fiona Behrens, Daniel Almeida, linux-modules, Stephen Rothwell,
linux-next
In-Reply-To: <er7h34im2rk627usnvbre3clqvsx3uzev7kboy33pd7oac747c@nvtl7y2mmdde>
On 02/11/2025 10.56, Uwe Kleine-König wrote:
> Hello Daniel,
>
> [Adding Stephen and linux-next to Cc]
>
> On Sat, Nov 01, 2025 at 10:39:08PM +0100, Daniel Gomez wrote:
>> On 24/09/2025 14.39, Andreas Hindborg wrote:
>>> Extend the `module!` macro with support module parameters. Also add some
>>> string to integer parsing functions.
>>>
>>> Based on the original module parameter support by Miguel [1],
>>> later extended and generalized by Adam for more types [2][3].
>>> Originally tracked at [4].
>>>
>>> Link: https://github.com/Rust-for-Linux/linux/pull/7 [1]
>>> Link: https://github.com/Rust-for-Linux/linux/pull/82 [2]
>>> Link: https://github.com/Rust-for-Linux/linux/pull/87 [3]
>>> Link: https://github.com/Rust-for-Linux/linux/issues/11 [4]
>>> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
>>
>> I tested this series with rust_minimal module. They LGTM,
>>
>> Tested-by: Daniel Gomez <da.gomez@samsung.com>
>>
>> The patches did not apply cleanly to v6.18-rc3, at least not when using b4.
>> However, when applying them to the base commit and then rebasing onto v6.18-rc3,
>> I didn't see any conflicts.
>
> I don't know how you use b4, but
>
> git checkout v6.18-rc3
> b4 am -3 49af6d76-bcb7-4343-8903-390040e2c49b@kernel.org
> git am -3 ./v18_20250924_a_hindborg_rust_extend_module_macro_with_integer_parameter_support.mbx
>
> works fine on my end. Using `-3` should have the same effect as applying
> the series on top of the original base and rebase it.
Right, that's what I did but manually. I didn't know about that argument :).
>
> git fetch https://git.kernel.org/pub/scm/linux/kernel/git/modules/linux.git rebase/20250924-module-params-v3-v18-0-bf512c35d910@kernel.org
> git range-diff FETCH_HEAD...HEAD
>
> confirms that.
>
>> I've created a temporary branch with this rebase here:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/modules/linux.git/log/?h=rebase/20250924-module-params-v3-v18-0-bf512c35d910@kernel.org
>>
>> Can you take a look when you can? I'll merge this shortly after checking with
>> Uwe, as there are some minor conflicts with his tree.
>>
>> + Uwe
>>
>> These are the conflicts I see when merging the patch series from Michal [1]
>> (Introduce import_ns support for Rust). I believe these are trivial things that
>> we will get notified from linux-next merging. But let me know what you think as
>> you have requested in that thread.
>>
>> [1] Link: https://lore.kernel.org/all/20251028-pwm_fixes-v1-0-25a532d31998@samsung.com/
>
> Yeah, I expect that Stephen will highlight the conflicts, but I prefer
> to not be surprised by that and consider linux-next more a fallback
> security net that I don't want to use. I like it to be the other way
> round and tell Stephen about conflicts to expect :-)
Please Stephen, check the proposed changes below. I plan to merge this series in
modules' tree and it will conflict with Uwe's tree on rust/macros/module.rs file.
>
>> ...
>> Applying: rust: macros: Add support for 'imports_ns' to module!
>> Patch failed at 0008 rust: macros: Add support for 'imports_ns' to module!
>> error: patch failed: rust/macros/module.rs:98
>> error: rust/macros/module.rs: patch does not apply
>> hint: Use 'git am --show-current-patch=diff' to see the failed patch
>> hint: When you have resolved this problem, run "git am --continue".
>> hint: If you prefer to skip this patch, run "git am --skip" instead.
>> hint: To restore the original branch and stop patching, run "git am --abort".
>> hint: Disable this message with "git config set advice.mergeConflict false"
>>
>> git am --show-current-patch=diff
>
> That command shows the patch to apply, but not the conflict, let alone
> your resolution.
>
>> ---
>> rust/macros/module.rs | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>> ---
>> rust/macros/module.rs | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/rust/macros/module.rs b/rust/macros/module.rs
>> index 5ee54a00c0b65699596e660b2d4d60e64be2a50c..408cd115487514c8be79724d901c676435696376 100644
>> --- a/rust/macros/module.rs
>> +++ b/rust/macros/module.rs
>> @@ -98,6 +98,7 @@ struct ModuleInfo {
>> description: Option<String>,
>> alias: Option<Vec<String>>,
>> firmware: Option<Vec<String>>,
>> + imports_ns: Option<Vec<String>>,
>> }
>
> So here the addition of `params` is missing.
>
>> [...]
>
> When I merge your branch mentioned above with my pwm/for-next and
> resolve the merge conflicts, the resolution looks as follows. The only
> non-trivial thing is that
>
> if let Some(imports) = info.imports_ns {
>
> now needs a & for `info`.
Correct.
In case it's necessary, I've merged your changes into the modules's -next
branch and attach the diff for you and Stephen. Not sure which order trees are
taken/merged, though.
>
> Best regards
> Uwe
>
> diff --cc rust/macros/module.rs
> index d62e9c1e2a89,408cd1154875..000000000000
> --- a/rust/macros/module.rs
> +++ b/rust/macros/module.rs
> @@@ -205,50 -98,7 +205,51 @@@ struct ModuleInfo
> description: Option<String>,
> alias: Option<Vec<String>>,
> firmware: Option<Vec<String>>,
> + imports_ns: Option<Vec<String>>,
> + params: Option<Vec<Parameter>>,
> +}
> +
> +#[derive(Debug)]
> +struct Parameter {
> + name: String,
> + ptype: String,
> + default: String,
> + description: String,
> +}
> +
> +fn expect_params(it: &mut token_stream::IntoIter) -> Vec<Parameter> {
> + let params = expect_group(it);
> + assert_eq!(params.delimiter(), Delimiter::Brace);
> + let mut it = params.stream().into_iter();
> + let mut parsed = Vec::new();
> +
> + loop {
> + let param_name = match it.next() {
> + Some(TokenTree::Ident(ident)) => ident.to_string(),
> + Some(_) => panic!("Expected Ident or end"),
> + None => break,
> + };
> +
> + assert_eq!(expect_punct(&mut it), ':');
> + let param_type = expect_ident(&mut it);
> + let group = expect_group(&mut it);
> + assert_eq!(group.delimiter(), Delimiter::Brace);
> + assert_eq!(expect_punct(&mut it), ',');
> +
> + let mut param_it = group.stream().into_iter();
> + let param_default = expect_param_default(&mut param_it);
> + let param_description = expect_string_field(&mut param_it, "description");
> + expect_end(&mut param_it);
> +
> + parsed.push(Parameter {
> + name: param_name,
> + ptype: param_type,
> + default: param_default,
> + description: param_description,
> + })
> + }
> +
> + parsed
> }
>
> impl ModuleInfo {
> @@@ -263,7 -113,7 +264,8 @@@
> "license",
> "alias",
> "firmware",
> + "imports_ns",
> + "params",
> ];
> const REQUIRED_KEYS: &[&str] = &["type", "name", "license"];
> let mut seen_keys = Vec::new();
> @@@ -289,7 -139,7 +291,8 @@@
> "license" => info.license = expect_string_ascii(it),
> "alias" => info.alias = Some(expect_string_array(it)),
> "firmware" => info.firmware = Some(expect_string_array(it)),
> + "imports_ns" => info.imports_ns = Some(expect_string_array(it)),
> + "params" => info.params = Some(expect_params(it)),
> _ => panic!("Unknown key \"{key}\". Valid keys are: {EXPECTED_KEYS:?}."),
> }
>
> @@@ -329,25 -179,30 +332,30 @@@ pub(crate) fn module(ts: TokenStream) -
> // Rust does not allow hyphens in identifiers, use underscore instead.
> let ident = info.name.replace('-', "_");
> let mut modinfo = ModInfoBuilder::new(ident.as_ref());
> - if let Some(authors) = info.authors {
> + if let Some(authors) = &info.authors {
> for author in authors {
> - modinfo.emit("author", &author);
> + modinfo.emit("author", author);
> }
> }
> - if let Some(description) = info.description {
> - modinfo.emit("description", &description);
> + if let Some(description) = &info.description {
> + modinfo.emit("description", description);
> }
> modinfo.emit("license", &info.license);
> - if let Some(aliases) = info.alias {
> + if let Some(aliases) = &info.alias {
> for alias in aliases {
> - modinfo.emit("alias", &alias);
> + modinfo.emit("alias", alias);
> }
> }
> - if let Some(firmware) = info.firmware {
> + if let Some(firmware) = &info.firmware {
> for fw in firmware {
> - modinfo.emit("firmware", &fw);
> + modinfo.emit("firmware", fw);
> }
> }
> - if let Some(imports) = info.imports_ns {
> ++ if let Some(imports) = &info.imports_ns {
> + for ns in imports {
> + modinfo.emit("import_ns", &ns);
> + }
> + }
>
> // Built-in modules also export the `file` modinfo string.
> let file =
The resolution looks good to me.
As I applied Michal's patch on top of Andreas changes, it looks like this on
my side:
diff --git a/rust/macros/module.rs b/rust/macros/module.rs
index d62e9c1e2a89..5bf0a487de50 100644
--- a/rust/macros/module.rs
+++ b/rust/macros/module.rs
@@ -206,6 +206,7 @@ struct ModuleInfo {
alias: Option<Vec<String>>,
firmware: Option<Vec<String>>,
params: Option<Vec<Parameter>>,
+ imports_ns: Option<Vec<String>>,
}
#[derive(Debug)]
@@ -264,6 +265,7 @@ fn parse(it: &mut token_stream::IntoIter) -> Self {
"alias",
"firmware",
"params",
+ "imports_ns",
];
const REQUIRED_KEYS: &[&str] = &["type", "name", "license"];
let mut seen_keys = Vec::new();
@@ -290,6 +292,7 @@ fn parse(it: &mut token_stream::IntoIter) -> Self {
"alias" => info.alias = Some(expect_string_array(it)),
"firmware" => info.firmware = Some(expect_string_array(it)),
"params" => info.params = Some(expect_params(it)),
+ "imports_ns" => info.imports_ns = Some(expect_string_array(it)),
_ => panic!("Unknown key \"{key}\". Valid keys are: {EXPECTED_KEYS:?}."),
}
@@ -348,6 +351,11 @@ pub(crate) fn module(ts: TokenStream) -> TokenStream {
modinfo.emit("firmware", fw);
}
}
+ if let Some(imports) = &info.imports_ns {
+ for ns in imports {
+ modinfo.emit("import_ns", &ns);
+ }
+ }
// Built-in modules also export the `file` modinfo string.
let file =
^ permalink raw reply related
* Re: [PATCH v8 04/23] slab: add sheaf support for batching kfree_rcu() operations
From: Harry Yoo @ 2025-11-03 3:17 UTC (permalink / raw)
To: Daniel Gomez
Cc: Vlastimil Babka, Suren Baghdasaryan, Liam R. Howlett,
Christoph Lameter, David Rientjes, Roman Gushchin,
Uladzislau Rezki, Sidhartha Kumar, linux-mm, linux-kernel, rcu,
maple-tree, linux-modules, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen, Aaron Tomlin, Lucas De Marchi
In-Reply-To: <0406562e-2066-4cf8-9902-b2b0616dd742@kernel.org>
On Fri, Oct 31, 2025 at 10:32:54PM +0100, Daniel Gomez wrote:
>
>
> On 10/09/2025 10.01, Vlastimil Babka wrote:
> > Extend the sheaf infrastructure for more efficient kfree_rcu() handling.
> > For caches with sheaves, on each cpu maintain a rcu_free sheaf in
> > addition to main and spare sheaves.
> >
> > kfree_rcu() operations will try to put objects on this sheaf. Once full,
> > the sheaf is detached and submitted to call_rcu() with a handler that
> > will try to put it in the barn, or flush to slab pages using bulk free,
> > when the barn is full. Then a new empty sheaf must be obtained to put
> > more objects there.
> >
> > It's possible that no free sheaves are available to use for a new
> > rcu_free sheaf, and the allocation in kfree_rcu() context can only use
> > GFP_NOWAIT and thus may fail. In that case, fall back to the existing
> > kfree_rcu() implementation.
> >
> > Expected advantages:
> > - batching the kfree_rcu() operations, that could eventually replace the
> > existing batching
> > - sheaves can be reused for allocations via barn instead of being
> > flushed to slabs, which is more efficient
> > - this includes cases where only some cpus are allowed to process rcu
> > callbacks (Android)
> >
> > Possible disadvantage:
> > - objects might be waiting for more than their grace period (it is
> > determined by the last object freed into the sheaf), increasing memory
> > usage - but the existing batching does that too.
> >
> > Only implement this for CONFIG_KVFREE_RCU_BATCHED as the tiny
> > implementation favors smaller memory footprint over performance.
> >
> > Also for now skip the usage of rcu sheaf for CONFIG_PREEMPT_RT as the
> > contexts where kfree_rcu() is called might not be compatible with taking
> > a barn spinlock or a GFP_NOWAIT allocation of a new sheaf taking a
> > spinlock - the current kfree_rcu() implementation avoids doing that.
> >
> > Teach kvfree_rcu_barrier() to flush all rcu_free sheaves from all caches
> > that have them. This is not a cheap operation, but the barrier usage is
> > rare - currently kmem_cache_destroy() or on module unload.
> >
> > Add CONFIG_SLUB_STATS counters free_rcu_sheaf and free_rcu_sheaf_fail to
> > count how many kfree_rcu() used the rcu_free sheaf successfully and how
> > many had to fall back to the existing implementation.
> >
> > Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
>
> Hi Vlastimil,
>
> This patch increases kmod selftest (stress module loader) runtime by about
> ~50-60%, from ~200s to ~300s total execution time. My tested kernel has
> CONFIG_KVFREE_RCU_BATCHED enabled. Any idea or suggestions on what might be
> causing this, or how to address it?
This is likely due to increased kvfree_rcu_barrier() during module unload.
It currently iterates over all CPUs x slab caches (that enabled sheaves,
there should be only a few now) pair to make sure rcu sheaf is flushed
by the time kvfree_rcu_barrier() returns.
Just being curious, do you have any serious workload that depends on
the performance of module unload?
--
Cheers,
Harry / Hyeonggon
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox