内核Panic时调用call_usermodehelper无法执行用户空间程序的问题求助

问题背景 #

我需要在内核panic时通知U-Boot，已经配置好fw_setenv等工具，手动运行正常，但自动化过程遇到问题：

• 尝试用call_usermodehelper()在panic函数中调用用户程序，但返回0却没有实际执行；
• 测试过创建文件（touch /a.txt）也失败，文件没生成；
• 单独写内核模块测试call_usermodehelper()完全正常，但移植到panic函数里就失效；
• 尝试用workqueue异步执行，worker里的printk能输出，但用户程序还是没运行。

我的测试代码如下：

struct work_cont {
    struct work_struct real_work;
    char cmd[250];
};

static struct work_cont execwq;

void cmdexec_worker(struct work_struct *work)
{
    static char *envp[] = { "HOME=/", "TERM=linux", "PATH=/sbin:/usr/sbin:/bin:/usr/bin", NULL };
    char *argv[] = { "/bin/touch", "/a.txt", NULL };
    // struct work_cont *c_ptr = container_of(work, struct work_cont, real_work);

    set_current_state(TASK_INTERRUPTIBLE);
    printk(KERN_ERR "Executing worker\n");
    call_usermodehelper(argv[0], argv, envp, UMH_WAIT_EXEC);
    return;
}

void panic(const char *fmt, ...)
{
    schedule_work(&execwq.real_work);
    ...
}

static int __init setup_crash_kexec_post_notifiers(char *s)
{
    INIT_WORK(&execwq.real_work, cmdexec_worker);
    ...
}

问题分析与解决方案 #

看起来你遇到的是内核panic场景下，用户空间程序无法被正常唤起的典型问题，我来帮你拆解下核心原因和可行思路：

核心原因：Panic后的系统状态限制

内核panic是系统进入不稳定临界状态的标志，此时很多核心子系统已经停止工作或不可靠，而call_usermodehelper()依赖的多个内核服务都可能失效：

1. 文件系统只读锁定：panic触发后，内核默认会将根文件系统挂载为只读模式，这时候不管是touch创建文件，还是fw_setenv写入存储设备，都会因为权限问题失败；
2. 进程调度与子系统瘫痪：call_usermodehelper()需要内核创建新的用户进程，涉及进程管理、虚拟内存、VFS等多个子系统的协作，但panic后这些子系统可能已经停止服务，无法完成进程的fork/exec流程；
3. Workqueue的局限性：虽然你看到了worker的printk输出，说明worker函数被调用了，但此时系统的CPU调度、资源分配已经异常，call_usermodehelper()无法完成后续的用户程序启动流程。

代码细节优化

你的worker函数里的set_current_state(TASK_INTERRUPTIBLE);完全多余，worker进程本身就是可中断的，在panic场景下设置这个状态反而可能导致进程被挂起，建议直接删除这行代码。

可行解决方案

既然你的目标是修改U-Boot环境变量，我更推荐绕过用户空间，直接在内核层操作：

1. 内核直接读写U-Boot环境分区：找到U-Boot环境变量存储的物理设备（比如SPI Flash分区、MMC扇区），在内核panic回调中，通过内核驱动直接写入修改后的环境变量数据，不需要依赖fw_setenv这类用户工具，这是最可靠的方式；
2. 调整panic内核参数（仅作尝试）：如果坚持要用用户空间程序，可以设置内核参数panic=-1禁止panic后的自动重启，同时修改内核代码关闭panic时的根文件系统只读锁定，但这种方式可靠性极低，因为panic后的系统状态完全不可控；
3. 使用panic通知链：注册内核panic_notifier回调，在回调中执行最简操作，但同样要注意，回调中不能依赖复杂子系统，只能做最基础的硬件操作。

验证建议

你可以先在panic回调中打印根文件系统的只读状态：

printk(KERN_ERR "Root FS readonly: %d\n", sb_rdonly(root_vfs_sb));

确认是否是文件系统只读导致的操作失败，但即使解决了只读问题，后续的进程创建仍可能因为子系统瘫痪而失败。

备注：内容来源于stack exchange，提问作者RobertAA