Andrew Morton wrote: > What process is running here? Presumably modprobe.
Yes. It is a worker systemd-udevd process who is acting like modprobe . > A possible explanation is that modprobe has genuinely received a > SIGKILL. Can you identify anything in this setup which might send a > SIGKILL to the modprobe process? It is the systemd-udevd process who is sending SIGKILL to worker systemd-udevd processes. It uses hard coded 30 seconds timeout. > kthread_create_on_node() thinks that SIGKILL came from the oom-killer > and it cheerfully returns -ENOMEM, which is incorrect if that signal > came from userspace. And I don't _think_ we prevent > userspace-originated signals from unblocking > wait_for_completion_killable()? I prefer processes being killed upon SIGKILL as soon as possible. I expect any unkillable operations should be replaced with killable operations, or the OOM killer may fail to solve no memory state by choosing a process in unkillable sleep. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
