From nobody Thu Mar 28 13:41:11 2024 X-Original-To: bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4V54SS22KRz5FvJh for ; Thu, 28 Mar 2024 13:41:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V54SR66Q2z4cgq for ; Thu, 28 Mar 2024 13:41:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1711633271; a=rsa-sha256; cv=none; b=LSR/aL/cJnPOQHDOOocQ7Pdm0idEXgDMINabuZ3jN2qtFYWqkf8jsDAcegIe3uyzHfHOYQ HzJr3MIp9VPZ0Xe6cbfzfaT2Iewv/WAzV/7E5xhRfZw2MzH5liSByT8dGTB60Hsh3wXQkl BllmNbtThP7cGqaBIpQ9OQVzDsPR2ca95juWut6RxOtO6vb5EpC8nBEk81FjXXNReu+6PI N32S+33oi/THpZsxPdTMsPHLsAWTCFENqypfchdezePE0ks63e/u3sBXHQHnrXlJW/5r6b HlXVwQdsHS2PwNriy1pegmy0WPF+UjrNTCP8br3TBkTFGd6NZDuWC4deVVrp/Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1711633271; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=F27xBGu7fNYvJsL2HTnht9eAzLCPay1Tox9ld4rqM3s=; b=cwwr2NYla6FCq3u8IMg23Mngi1qJA4TLrgAMkW+hpCWkHg7B9LPK+feWIe/6tidXupfGum KJl+yMIdWsLX7SFZOmXgaQxmK1re3mWaKcG7xl1nu1Ckc2+4XjC7FiGqwYE/QLP+EOfXH4 ++1UmTyMOFsIjqN2a0+LdEu437CcHowuIGqLBMg35rBwc9SxRWLPiCeDaBkq1Dm/PiGNbr oP6C55sw2iBBR1b61c+NM83KOjyWk81ZWwNxPwoBb7XlkhV8K92GNmnVQUo1hhEFAmlw6K LwibXINYxOSMgL2I6wvbB4xGF7JhcYBzXpRUF8nke0uqv/XPvmt66OzBBPAF+A== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4V54SR5jZ0zV5H for ; Thu, 28 Mar 2024 13:41:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 42SDfBs6001295 for ; Thu, 28 Mar 2024 13:41:11 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 42SDfBkW001294 for bugs@FreeBSD.org; Thu, 28 Mar 2024 13:41:11 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f 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 Date: Thu, 28 Mar 2024 13:41:11 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: junchoon@dec.sakura.ne.jp X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D277967 Tomoaki AOKI changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |junchoon@dec.sakura.ne.jp --- Comment #1 from Tomoaki AOKI --- 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.=