kmod: fix wait on recursive loop

Recursive loops with module loading were previously handled in kmod by
restricting the number of modprobe calls to 50 and if that limit was
breached request_module() would return an error and a user would see the
following on their kernel dmesg:

  request_module: runaway loop modprobe binfmt-464c
  Starting init:/sbin/init exists but couldn't execute it (error -8)

This issue could happen for instance when a 64-bit kernel boots a 32-bit
userspace on some architectures and has no 32-bit binary format
hanlders.  This is visible, for instance, when a CONFIG_MODULES enabled
64-bit MIPS kernel boots a into o32 root filesystem and the binfmt
handler for o32 binaries is not built-in.

After commit 6d7964a722af ("kmod: throttle kmod thread limit") we now
don't have any visible signs of an error and the kernel just waits for
the loop to end somehow.

Although this *particular* recursive loop could also be addressed by
doing a sanity check on search_binary_handler() and disallowing a
modular binfmt to be required for modprobe, a generic solution for any
recursive kernel kmod issues is still needed.

This should catch these loops.  We can investigate each loop and address
each one separately as they come in, this however puts a stop gap for
them as before.

Fixes: 6d7964a722af ("kmod: throttle kmod thread limit")
Signed-off-by: Luis R. Rodriguez <>
Reported-by: Matt Redfearn <>
Tested-by: Matt Redfearn <>
Cc: "Eric W. Biederman" <>
Cc: Colin Ian King <>
Cc: Dan Carpenter <>
Cc: Daniel Mentz <>
Cc: David Binderman <>
Cc: Dmitry Torokhov <>
Cc: Ingo Molnar <>
Cc: Jessica Yu <>
Cc: Josh Poimboeuf <>
Cc: Kees Cook <>
Cc: Michal Marek <>
Cc: Miroslav Benes <>
Cc: Peter Zijlstra (Intel) <>
Cc: Petr Mladek <>
Cc: Rusty Russell <>
Cc: Shuah Khan <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
1 file changed