Date: Thu, 28 Mar 2024 13:41:11 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 277967] The loader should fail gracefully when /boot/loader.conf attempts to load a module that is too large Message-ID: <bug-277967-227-TXfUMsuiuq@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-277967-227@https.bugs.freebsd.org/bugzilla/> References: <bug-277967-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D277967 Tomoaki AOKI <junchoon@dec.sakura.ne.jp> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |junchoon@dec.sakura.ne.jp --- Comment #1 from Tomoaki AOKI <junchoon@dec.sakura.ne.jp> --- This needs considerations for modules which depends on other modules. Possibly, the first module could be loaded fine, but exceeds the limit when attempting to load its dependencies, and at worse, the first module cannot = be unloaded safely. So multiple (at least 2) passes would be needed to actually load modules. For example, nvidia-drm.ko depends on nvidia-modeset.ko, nvidia.ko and drm.= ko (possibly more implicit). Possible option would be to include module sizes in linker.hints files. And looking output of kldstat, dependencies seems to be loaded after at lea= st one of its consumers. To avoid this, 1. read /boot/loader.conf[.local] thoroughly to determine all modules specified to load, 2. read linker.hints in all module directories to determine dependencies, 3. at the same time of 2., fetch sizes of modules to be loaded, 4. decide the loading order, basically the order appears in /boot/loader.conf[.local], but dependencies should be loaded before their first consumers, 5. finally decide to which to be loaded (which to ignore) and actually load modules. But at the same time, considerations would be needed for the cases linker.h= ints are somehow not up-to-date or nonexistent. This could happen when admins just copies pre-built modules but fotgot to r= un kldxref, or kldxref somehow failed to run (crash?). Anyway, would be complicated. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-277967-227-TXfUMsuiuq>