Busybox modprobe hitch with kernel 5.10

Denys Vlasenko vda.linux at googlemail.com
Thu Dec 31 00:14:52 UTC 2020


On Wed, Dec 30, 2020 at 12:28 PM Jessica Yu <jeyu at kernel.org> wrote:
> +++ Lauri Kasanen [30/12/20 10:08 +0200]:
> >On Tue, 29 Dec 2020 22:05:21 +0100
> >Denys Vlasenko <vda.linux at googlemail.com> wrote:
> >
> >> On Mon, Dec 28, 2020 at 6:15 PM Lauri Kasanen <cand at gmx.com> wrote:
> >> > Hi,
> >> >
> >> > On Busybox 1.31.1, modprobing any module for the 5.10 kernel prints a
> >> > nasty message:
> >> > Module has invalid ELF header
> >> >
> >> > but the module loads successfully after that. So looks like bb tries
> >> > two paths, the first fails, second succeeds.
> >>
> >> What does strace show?
> >
> >openat(AT_FDCWD, "kernel/drivers/char/ppdev.ko.gz", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
> >SYS_350(0x3, 0x80b37d5, 0, 0xb7d794b7, 0x3) = -1 ENOEXEC (Exec format error)
> >close(3)                                = 0
> >openat(AT_FDCWD, "kernel/drivers/char/ppdev.ko.gz", O_RDONLY|O_LARGEFILE) = 3
> >read(3, "\37\213", 2)                   = 2
> >read(3, "\10\0\0\0\0\0\2\3\214V\5p\333h\26\226l'\345\332s\353\366\312\350\36S\2713\245\364<Z\366]\246\256\322\300\25\226\335\36\25\344\300b\\E\327\374\367\227{\314\314\214q\3219g\32{\247\214.\315\6\n\326*\273S\256\353\346\252}\357Ir\262\274\236\261\364\376\367\177\17\376\7\277\336K\322\243\367\213"..., 16384) = 4363
> >read(3, "", 12021)                      = 0
> >read(3, "", 16384)                      = 0
> >close(3)                                = 0
> >init_module(0x921b9c0, 10100, "")       = 0
> >
> >Full log attached. Repros on both x86 and x86_64, and the modules are gzip compressed.
> >
> >- Lauri
>
> Ah, I see what's happening. modprobe normally tries finit_module()
> first, and falls back to init_module() for compressed modules, which
> is the case here. We added new error messages as part of an effort to
> demystify module loader errors, since sometimes we don't always know
> why a module fails to load (See upstream kernel commit: 14721add58ef).
>
> Since loading compressed modules will always produce this message from
> finit_module(), I would be fine with removing the message for now as a
> workaround. Perhaps the long-term solution would be to teach
> finit_module() to work with compressed modules. Wenruo, since you were
> the commit author, would you be fine with dropping the pr_err() message?

I can add a condition to not try finit_module() on compressed modules,
however, I anticipate needing to revert it when kernel learns how to load
compressed modules as well.


More information about the busybox mailing list