From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f73.google.com (mail-wm1-f73.google.com [209.85.128.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 32B5634D910 for ; Thu, 26 Mar 2026 21:21:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774560095; cv=none; b=CJw70MS/K2hUDQJMPoMvSVFBfSeObjvUowLxvufmENorh3NIH6sD0e3NB8J6uWzL6yTZzw9dFKDNY8U53CZhMvLJvwyVwEqQNkgG+6au2S0uxuzKXXSP6lTV4/N0BBEzWF5fH0sYK27cXMVKquDijtEvZ2mspHFUqoO2q+yGUm4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774560095; c=relaxed/simple; bh=bNpRj84rrM86rZbfxqGsulk194sj2YCQCbqiinFXn0k=; h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=dX5jW6c8oCCFyYSylVAnDyrbRv8vWJ/GpPbkOTC7agcshfCVpP8XGRBlNnXH4FjGx+0D3pbTR3kfROk3l6g6zsv+4RhNmW5Hq9QGX932VAH/a1GBmvMCM+sOkMb7G9u5MfsXhDNOYp54KdGFXQcRWHlMZ5oeuPXXirFok7sxAUY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--sidnayyar.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=Le4ocxKa; arc=none smtp.client-ip=209.85.128.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--sidnayyar.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Le4ocxKa" Received: by mail-wm1-f73.google.com with SMTP id 5b1f17b1804b1-487018c8244so12364965e9.3 for ; Thu, 26 Mar 2026 14:21:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1774560093; x=1775164893; darn=vger.kernel.org; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=1JDEAfTveFPPp/Cvp9vb5cLHHVQOeJ1kP6lbtNESx5U=; b=Le4ocxKai1ampYgMBGWZxspAF7HBZcon9mxYRtoO1rnFV7y63tzYecLZiyxgtj1gPi 71+GStzMHfO2wtexvEGNK5lmNzlf2rdhGJJsQ4GAItRCLrnwvU5PmsG+CE7hak3SyYhM Edx8V7GoJQZztBS9uMaNyYaXHXVi3lQ1mG5kGOQBBv/nIjUgFTu3f0LI+vGwYD2pkgMt eF6Oc/SZLPY4SCmf7/rYW9Sw+eksBfg4NzwM9Kt+yLBKkMwyH/h4ReDzUW2yyJHdLO0A yFnhFdxWe/BK1MVxXqSDHWyZcIBezZSJF8rl59G51apKv4t6WdEJ5pP+ZvX1V+VVTmTx yERQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774560093; x=1775164893; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=1JDEAfTveFPPp/Cvp9vb5cLHHVQOeJ1kP6lbtNESx5U=; b=p1QRri6HlDIuK3qoT56vjPfZUP9c5BmHSxLjHz8sh83LjguthLnW5+6+eQGM+fuNMG yqTjiKtURPKfDCOk0wWnAiT27Ci3bRO0BBiJde/3gYWFJv1M9xIakjKBIsT0gs8njGTU x0g+xhBe/0alNz2P1guEo7QCb969k1owdhmzz6Vm5qhreWal8cmmhuUSc3nU70x9i1qU K8upnQlidj36aemenhkK+MUp9Oi5k51FgR0m5Ix39Rkkfhiu0c3dKePVQ4qvcxHi2KHr 8+YQK6BX4bxqZYOrIeMyLSJ/iDg/FgnPlgK/AbKyFN9c8w1xj4Jm/TMhpfPJD5BIMcQ7 FUvA== X-Forwarded-Encrypted: i=1; AJvYcCX8mm6oBINMUOBm9YBZ3RwgpzY7QyanSwTkEsmHo9HmlTN1xnFTeCAgUsB39/PPjGOwnFccoeyeDSI=@vger.kernel.org X-Gm-Message-State: AOJu0YwZv/QZHB0UgNWlUhnwJT1iVEKr8xFDzpssuRGs2uuExkdZULOj bsH1ENk1zFooZGaETOQgYfmdTojNtuBTucOIRcs6P5suSPcH9IGCsUoV+YWut02wBj/5HFFv4lO 93Vtfr61qdP1ZRFUD9Q== X-Received: from wmfx22.prod.google.com ([2002:a05:600c:2d16:b0:486:fd53:605d]) (user=sidnayyar job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:8b03:b0:483:8062:b2f with SMTP id 5b1f17b1804b1-48727ef16aemr3148245e9.6.1774560092608; Thu, 26 Mar 2026 14:21:32 -0700 (PDT) Date: Thu, 26 Mar 2026 21:21:28 +0000 Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-B4-Tracking: v=1; b=H4sIAFijxWkC/23MQQ7CIBRF0a00fywGKVDiyH2YDoB+KLEWAw3RN Oxd7NjhfXk5O2RMATNcux0SlpBDXFuIUwd21qtHEqbWwCiTtKeCPNyifd60IeKiqUKHE+Mc2v+ V0IX3Yd3H1nPIW0yfgy78t/5TCieUSD1I45RRvR1uPka/4NnGJ4y11i/v+hXqowAAAA== X-Change-Id: 20260305-kflagstab-51a08efed244 X-Mailer: b4 0.14.3 Message-ID: <20260326-kflagstab-v5-0-455cd723dddf@google.com> Subject: [PATCH v5 0/7] scalable symbol flags with __kflagstab From: Siddharth Nayyar To: Luis Chamberlain , Petr Pavlu , Daniel Gomez , Sami Tolvanen , Aaron Tomlin , Arnd Bergmann , Nathan Chancellor , Nicolas Schier , Jonathan Corbet , Shuah Khan Cc: linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-doc@vger.kernel.org, Siddharth Nayyar , gprocida@google.com Content-Type: text/plain; charset="utf-8" This patch series implements a mechanism for scalable exported symbol flags using a separate section called __kflagstab. The series introduces __kflagstab support, removes *_gpl sections in favor of a GPL flag, simplifies symbol resolution during module loading. The __kflagstab contains an 8-bit bitset which can represent up to 8 boolean flags per symbol exported in the __ksymtab. The patch series also uses this bitset to store GPL-only flag values for kernel symbols, thereby eliminating the need for *_gpl sections for representing GPL only symbols. Petr Pavlu ran a small test to get a better understanding of the different section sizes resulting from this patch series. He used v6.17-rc6 together with the openSUSE x86_64 config [1], which is fairly large. The resulting vmlinux.bin (no debuginfo) had an on-disk size of 58 MiB, and included 5937 + 6589 (GPL-only) exported symbols. The following table summarizes his measurements and calculations regarding the sizes of all sections related to exported symbols: | HAVE_ARCH_PREL32_RELOCATIONS | !HAVE_ARCH_PREL32_RELOCATIONS Section | Base [B] | Ext. [B] | Sep. [B] | Base [B] | Ext. [B] | Sep. [B] ---------------------------------------------------------------------------------------- __ksymtab | 71244 | 200416 | 150312 | 142488 | 400832 | 300624 __ksymtab_gpl | 79068 | NA | NA | 158136 | NA | NA __kcrctab | 23748 | 50104 | 50104 | 23748 | 50104 | 50104 __kcrctab_gpl | 26356 | NA | NA | 26356 | NA | NA __ksymtab_strings | 253628 | 253628 | 253628 | 253628 | 253628 | 253628 __kflagstab | NA | NA | 12526 | NA | NA | 12526 ---------------------------------------------------------------------------------------- Total | 454044 | 504148 | 466570 | 604356 | 704564 | 616882 Increase to base [%] | NA | 11.0 | 2.8 | NA | 16.6 | 2.1 The column "HAVE_ARCH_PREL32_RELOCATIONS -> Base" contains themeasured numbers. The rest of the values are calculated. The "Ext." column represents an alternative approach of extending __ksymtab to include a bitset of symbol flags, and the "Sep." column represents the approach of having a separate __kflagstab. With HAVE_ARCH_PREL32_RELOCATIONS, each kernel_symbol is 12 B in size and is extended to 16 B. With !HAVE_ARCH_PREL32_RELOCATIONS, it is 24 B, extended to 32 B. Note that this does not include the metadata needed to relocate __ksymtab*, which is freed after the initial processing. The base export data in this case totals 0.43 MiB. About 50% is used for storing the names of exported symbols. Adding __kflagstab as a separate section has a negligible impact, as expected. When extending __ksymtab (kernel_symbol) instead, the worst case with !HAVE_ARCH_PREL32_RELOCATIONS increases the export data size by 16.6%. Note that the larger increase in size for the latter approach is due to 4-byte alignment of kernel_symbol data structure, instead of 1-byte alignment for the flags bitset in __kflagstab in the former approach. Based on the above, it was concluded that introducing __kflagstab makes senses, as the added complexity is minimal over extending kernel_symbol, and there is overall simplification of symbol finding logic in the module loader. Thank you Petr Pavlu for doing a section size analysis as well as Sami Tolvanen, Petr Pavlu and Jonathan Corbet for their valuable feedback. --- Changes from v4: - squashed patches #4 and #5 to fix a bisecting issue v4: https://lore.kernel.org/r/20260305-kflagstab-v4-0-6a76bf8b83c7@google.com Changes from v3: - made commit messages more descriptive v3: https://lore.kernel.org/20251103161954.1351784-1-sidnayyar@google.com/ Changes from v2: - dropped symbol import protection to spin off into its own series v2: https://lore.kernel.org/20251013153918.2206045-1-sidnayyar@google.com/ Changes from v1: - added a check to ensure __kflagstab is present - added warnings for the obsolete *_gpl sections - moved protected symbol check before ref_module() call - moved protected symbol check failure warning to issue detection point v1: https://lore.kernel.org/20250829105418.3053274-1-sidnayyar@google.com/ [1] https://github.com/openSUSE/kernel-source/blob/307f149d9100a0e229eb94cbb997ae61187995c3/config/x86_64/default Signed-off-by: Siddharth Nayyar Reviewed-by: Petr Pavlu --- Siddharth Nayyar (7): module: define ksym_flags enumeration to represent kernel symbol flags module: add kflagstab section to vmlinux and modules module: populate kflagstab in modpost module: use kflagstab instead of *_gpl sections module: deprecate usage of *_gpl sections in module loader module: remove *_gpl sections from vmlinux and modules documentation: remove references to *_gpl sections Documentation/kbuild/modules.rst | 11 +++-- include/asm-generic/vmlinux.lds.h | 21 +++----- include/linux/export-internal.h | 28 +++++++---- include/linux/module.h | 4 +- include/linux/module_symbol.h | 5 ++ kernel/module/internal.h | 4 +- kernel/module/main.c | 101 ++++++++++++++++++-------------------- scripts/mod/modpost.c | 16 ++++-- scripts/module.lds.S | 3 +- 9 files changed, 98 insertions(+), 95 deletions(-) --- base-commit: 0138af2472dfdef0d56fc4697416eaa0ff2589bd change-id: 20260305-kflagstab-51a08efed244 Best regards, -- Siddharth Nayyar