On Thu, Dec 31, 2020 at 1:45 AM Qu Wenruo <[email protected]> wrote: > >> 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? > > Not exactly. > > In fact, the error message matches what the > init_module(2)/finit_module(2) says: > > init_module() loads an ELF image into kernel space, performs any > necessary symbol relocations ... > > We're not supposed to load compressed data from the very first place, > thus the ELF header check is valid, and doing its work. > > And consider such case, where a kernel module is really corrupted, > without the message, how would the end user really know what's going wrong? > > Not every end user would be able to add extra pr_*() calls into the > kernel and find out the problem. > > Really, it's the user space module loader not doing it proper checking.
User space module loader has no idea whether kernel can accept a gzipped or xz-ed module via finit_module(). > > 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. > > > > If kernel is really going to detect compressed module, the decompression > should happen before we check the ELF header, thus the error message > should still be there. I was talking from the userspace perspective: is there a reasonable way to be more careful for userspace? No, unless userspace assumes that finit_module() will *never* be extended to handle .ko.gz modules. _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
