[PATCH] rv: Fix boot failure when kernel lockdown is active

From: Xiu Jianfeng <xiujianfeng@huawei.com>

When booting kernel with lockdown=confidentiality parameter, the system
will hang at rv_register_reactor() due to waiting for rv_interface_lock,
as shown in the following log,

INFO: task swapper/0:1 blocked for more than 122 seconds.
      Not tainted 6.17.0-rc6-next-20250915+ #29
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:swapper/0       state:D stack:0     pid:1     tgid:1     ppid:0
Call Trace:
 <TASK>
 __schedule+0x492/0x1600
 schedule+0x27/0xf0
 schedule_preempt_disabled+0x15/0x30
 __mutex_lock.constprop.0+0x538/0x9e0
 ? vprintk+0x18/0x50
 ? _printk+0x5f/0x90
 __mutex_lock_slowpath+0x13/0x20
 mutex_lock+0x3b/0x50
 rv_register_reactor+0x48/0xe0
 ? __pfx_register_react_printk+0x10/0x10
 register_react_printk+0x15/0x20
 do_one_initcall+0x5d/0x340
 kernel_init_freeable+0x351/0x540
 ? __pfx_kernel_init+0x10/0x10
 kernel_init+0x1b/0x200
 ? __pfx_kernel_init+0x10/0x10
 ret_from_fork+0x1fb/0x220
 ? __pfx_kernel_init+0x10/0x10
 ret_from_fork_asm+0x1a/0x30

The root cause is that, when the kernel lockdown is in confidentiality
mode, rv_create_dir(), which is essentially tracefs_create_dir(), will
return NULL. This, in turn, causes create_monitor_dir() to return
-ENOMEM, and finally leading to the mutex not being unlocked.

Fixes: 24cbfe18d55a ("rv: Merge struct rv_monitor_def into struct rv_monitor")
Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com>
---
 kernel/trace/rv/rv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/trace/rv/rv.c b/kernel/trace/rv/rv.c
index 1482e91c39f4..e35565dd2dc5 100644
--- a/kernel/trace/rv/rv.c
+++ b/kernel/trace/rv/rv.c

@@ -805,7 +805,7 @@ int rv_register_monitor(struct rv_monitor *monitor, struct rv_monitor *parent)
 
 	retval = create_monitor_dir(monitor, parent);
 	if (retval)
-		return retval;
+		goto out_unlock;
 
 	/* keep children close to the parent for easier visualisation */
 	if (parent)

-- 
2.43.0

On Wed, 2025-09-17 at 12:57 +0000, Xiu Jianfeng wrote:

From: Xiu Jianfeng <xiujianfeng@huawei.com>

When booting kernel with lockdown=confidentiality parameter, the
system
will hang at rv_register_reactor() due to waiting for
rv_interface_lock,
as shown in the following log,

Thanks for finding this, the problem was already fixed in [1], which is
on its way to getting merged.

[1] -
https://lore.kernel.org/all/20250903065112.1878330-1-zhen.ni@easystack.cn

Gabriele Monaco [off-list ref] writes:

On Wed, 2025-09-17 at 12:57 +0000, Xiu Jianfeng wrote:

quoted

From: Xiu Jianfeng <xiujianfeng@huawei.com>

When booting kernel with lockdown=confidentiality parameter, the
system
will hang at rv_register_reactor() due to waiting for
rv_interface_lock,
as shown in the following log,

Thanks for finding this, the problem was already fixed in [1], which is
on its way to getting merged.

[1] -
https://lore.kernel.org/all/20250903065112.1878330-1-zhen.ni@easystack.cn

Yeah, but it is interesting that this is causing real boot problem. I
thought that commit merely fixes a theoretical bug. I guess this is an
even stronger motivation to use lock guards.

Nam

On Wed, 2025-09-17 at 16:07 +0200, Nam Cao wrote:

Gabriele Monaco [off-list ref] writes:

quoted

On Wed, 2025-09-17 at 12:57 +0000, Xiu Jianfeng wrote:

quoted

From: Xiu Jianfeng <xiujianfeng@huawei.com>

When booting kernel with lockdown=confidentiality parameter, the
system will hang at rv_register_reactor() due to waiting for
rv_interface_lock, as shown in the following log,

Thanks for finding this, the problem was already fixed in [1],
which is on its way to getting merged.

[1] -
https://lore.kernel.org/all/20250903065112.1878330-1-zhen.ni@easystack.cn

Yeah, but it is interesting that this is causing real boot problem. I
thought that commit merely fixes a theoretical bug. I guess this is
an even stronger motivation to use lock guards.

Yeah totally, I have the feeling that with the kernel there's no such a
thing as a "theoretical bug", kinda like a good consequence of Murphy's
Law.

But I agree, that's something we may want to do sooner than later.
I'm currently not refactoring the RV core so I won't be touching that
for a while, but any patch is more than welcome!

Gabriele

čt 18. 9. 2025 v 10:36 odesílatel Gabriele Monaco [off-list ref] napsal:

Yeah totally, I have the feeling that with the kernel there's no such a
thing as a "theoretical bug", kinda like a good consequence of Murphy's
Law.

My understanding of "theoretical bug" is that it's code that is
semantically equivalent to a bug-free code, but becomes buggy after
doing an "innocent" change. The bug might be more or less
"theoretical" based on how "innocent" that change is. Of course, in a
codebase of the size of a Linux kernel, this tends to happen quite
often, and is not always possible to get rid of completely...

Tomas

On Thu, 2025-09-18 at 11:48 +0200, Tomas Glozar wrote:

čt 18. 9. 2025 v 10:36 odesílatel Gabriele Monaco [off-list ref] napsal:

quoted

Yeah totally, I have the feeling that with the kernel there's no such a
thing as a "theoretical bug", kinda like a good consequence of Murphy's
Law.

My understanding of "theoretical bug" is that it's code that is
semantically equivalent to a bug-free code, but becomes buggy after
doing an "innocent" change. The bug might be more or less
"theoretical" based on how "innocent" that change is. Of course, in a
codebase of the size of a Linux kernel, this tends to happen quite
often, and is not always possible to get rid of completely...

Yeah good point, we are getting philosophical here :) . This wasn't a
theoretical bug then, just something you don't think will really happen (a
failure creating a sysfs directory) ... until it happens.

The fact there is a way to make that function fail on-demand (kernel lockdown),
makes it just more "real". Moral of the story, better get the compiler check
things for you (lock guards).

Anyway the fix is now upstream.

Gabriele

Gabriele Monaco [off-list ref] writes:

Moral of the story, better get the compiler check things for you (lock
guards).

I will make the patches, once I'm done with some other things..

Nam