Export required symbols in nvidia.ko and nvidia-modeset.ko for their consumers
ClosedPublic
Actions

Authored by junchoon_dec.sakura.ne.jp on Nov 29 2025, 4:10 PM.

Details

Reviewers

emaste
kbowling
ashafer
imp

Group Reviewers

x11

Commits

R11:1587486a39ec: x11/nvidia-kmod{-devel}: Export required symbols

Summary

When kernel linker disables local symbol resolution, kernel modules
that require local symbols in other kernel modules, which are not
explicitly exported, stops to be loaded.

This behavior was turned on by default on main branch of src
at commit base 9562994a7aacee2baae6ddee1a7b558b48ae39ef.

Export local symbols in nvidia.ko for nvidia-modeset.ko and
in nvidia-modeset.ko for nvidia-drm.ko.

PR: 291212

Diff Detail

Repository

R11 FreeBSD ports repository

Lint

Lint Skipped

Unit

Tests Skipped

Event Timeline

junchoon_dec.sakura.ne.jp requested review of this revision.Nov 29 2025, 4:10 PM

junchoon_dec.sakura.ne.jp created this revision.

So why can't the coonsumers of these symbols just depend on the module? Why do we have to export the symbols from these modules to everybody?

If nvidia.ko hesitates to load due to the absense of linux*.ko, maybe src (main branch) would be needed to catch up with commit base e00a781c216cb12603a0a71c9ca293dde3e06250.

For testing on other branches, LINUX option would be needed to be disabled for x11/nvidia-kmod[-devel].
As my main branch (of src) environment is too outdated, I've tested tihs way on stable/15 and confirmed nvidia.ko and nvidia-modeset.ko are loadable.

In D53987#1233511, @imp wrote:

So why can't the coonsumers of these symbols just depend on the module? Why do we have to export the symbols from these modules to everybody?

The dependendies are already defined from before. But EXPORT_SYMS in Makefiles of each modules were missing.
And even without this, modules worked fine until debug.link_elf_obj_leak_locals=1 was the default.

It is better to provide an explicit list of symbols than just EXPORT_SYMS=YESunless we are sure that all symbols should be exported. But, this enough to preserve the status quo at least.

In D53987#1233515, @emaste wrote:

It is better to provide an explicit list of symbols than just EXPORT_SYMS=YESunless we are sure that all symbols should be exported. But, this enough to preserve the status quo at least.

I've tried it first, but it resulted in new symbol to appear, appear, and appear as error and gave up.
graphics/drm-*-kmod (at least graphics/drm-66-kmod) does the same thing, maybe because of
the same struggles.

emaste accepted this revision.Nov 29 2025, 5:25 PM

This revision is now accepted and ready to land.Nov 29 2025, 5:25 PM

I'm ok with for now just enabling all symbol exports to unblock things and then figure out how to clean things up in post.

In D53987#1233523, @adrian wrote:

I'm ok with for now just enabling all symbol exports to unblock things and then figure out how to clean things up in post.

How do you think about the threshold to use EXPORT_SYMS= YES or list per-symbols?
Even tens or hundreds (or even unlimited depending of codes) to be listed?

Yes, I know exposing really local symbols could be security risks. But maybe taking well balances considering maintainability may be wanted, not limiting with nvidia case.

Compared precisely between nvidia.ko, nvidia-modeset.ko and nvidia-drm.ko.
Turned out that 8 symbols are common to nvidia.ko and nvidia-drm.ko.
nvidia-modeset.ko didn't actually needed to be patched.

So created patch to limit to those symbols instead of "EXPORT_SYMS= YES".

As there's no need to rebuild graphics/nvidia-drm-*-kmod[-devel],
bumped PORTREVISION only for x11/nvidia-kmod[-devel] that need rebuilds.

Tested on stable/15 at commit base 4e48e50ea5982387a1c9f164953315f7fe1f76a3
and main at commit base 7685aaea8850f5b6995a17740a016019e0956c70,
with driver version 590.48.01 (now landed on main branch of ports tree).

This revision now requires review to proceed.Sat, Jan 3, 10:23 AM

So this looks to be a good way to resolve this.
While EXPORT_SYMS=NO was the default (export nothing) was too restrictive, =YES was a bit too libearal. There's a 'middle' class of symbol that is 'exported from the current module' which C doesn't have a good concept of.
Ideally, these would somehow be marked in the source, but since we don't have that infrastructure, these patches are the next best thing.

This revision is now accepted and ready to land.Sat, Jan 3, 10:27 AM

kbowling accepted this revision.Sat, Jan 3, 10:28 AM

Also, port maintainers often do not monitor Phabricator, so you may need to file a followup Bugzilla request once everyone is happy here. Try to make sure only one or the other is open.

@ashafer is this something you can lift into the upstream driver?

Closed by commit R11:1587486a39ec: x11/nvidia-kmod{-devel}: Export required symbols (authored by junchoon_dec.sakura.ne.jp, committed by Kevin Bowling <kbowling@FreeBSD.org>). · Explain WhySat, Jan 3, 10:35 AM

This revision was automatically updated to reflect the committed changes.

Kevin Bowling <kbowling@FreeBSD.org> added a commit: R11:1587486a39ec: x11/nvidia-kmod{-devel}: Export required symbols.

In D53987#1244732, @imp wrote:

Also, port maintainers often do not monitor Phabricator, so you may need to file a followup Bugzilla request once everyone is happy here. Try to make sure only one or the other is open.

As I've described on summary, the original report was Bug 291212 (closed by the reporter as the default was reverted back to previous for stab week on November). And I've intentionally uploaded renewed patch there, too.

ziaee added a subscriber: ziaee.Sat, Jan 3, 4:37 PM

ziaee added inline comments.

x11/nvidia-kmod/Makefile
70	Sorry I'm late, what if we gave this a descriptive name?

junchoon_dec.sakura.ne.jp added inline comments.Sat, Jan 3, 6:47 PM

x11/nvidia-kmod/Makefile
70	I've wondered which way to go, too. And decided to make which file to be patched clear and leave comments in Makefile instead of descriptive name, thus, intentional. The reason why is that keeping "self descriptive for target filename" makes far more easier to determine build errors when upstream merged the patch into official tarball (happened multiple times before) at some version.