This repo vendors github.com/NVIDIA/go-nvlib v0.12.0 (vendor/github.com/NVIDIA/go-nvlib/pkg/nvlib/info/root.go), pulled in both directly and through github.com/NVIDIA/nvidia-container-toolkit/pkg/nvcdi, and used from internal/rm, internal/plugin, internal/resource, and the plugin, gfd, and mps-control-daemon entrypoints.
That version has the bug from NVIDIA/go-nvlib#107: tryResolveLibrary resolves each candidate path with filepath.EvalSymlinks but never checks whether the result is a regular file. EvalSymlinks succeeds for directories too, so a stray directory named after a library in an earlier search path, for example /usr/lib64/libnvidia-ml.so.1, shadows the real library found later under /usr/lib/x86_64-linux-gnu. Driver library discovery here can end up pointing at a directory instead of the real .so.
The fix ("Skip non-regular files in tryResolveLibrary") is merged in NVIDIA/go-nvlib#108, but go-nvlib hasn't tagged a release past v0.12.0, so a normal go get -u won't pick it up yet.
Once go-nvlib cuts a release with #108 in it, or if a pseudo-version pin to the merge commit a9dc4f8 works as a stopgap, this repo's go.mod and vendor tree need the bump. nvidia-container-toolkit vendors the same broken copy directly (filed as NVIDIA/nvidia-container-toolkit#1966), and this repo pulls it in a second time through that module.
Closed issue: NVIDIA/go-nvlib#107
Merged fix: NVIDIA/go-nvlib#108
Same issue in nvidia-container-toolkit: NVIDIA/nvidia-container-toolkit#1966
I can open the dependency bump PR once a release or pseudo-version is agreed on.
This repo vendors github.com/NVIDIA/go-nvlib v0.12.0 (vendor/github.com/NVIDIA/go-nvlib/pkg/nvlib/info/root.go), pulled in both directly and through github.com/NVIDIA/nvidia-container-toolkit/pkg/nvcdi, and used from internal/rm, internal/plugin, internal/resource, and the plugin, gfd, and mps-control-daemon entrypoints.
That version has the bug from NVIDIA/go-nvlib#107: tryResolveLibrary resolves each candidate path with filepath.EvalSymlinks but never checks whether the result is a regular file. EvalSymlinks succeeds for directories too, so a stray directory named after a library in an earlier search path, for example /usr/lib64/libnvidia-ml.so.1, shadows the real library found later under /usr/lib/x86_64-linux-gnu. Driver library discovery here can end up pointing at a directory instead of the real .so.
The fix ("Skip non-regular files in tryResolveLibrary") is merged in NVIDIA/go-nvlib#108, but go-nvlib hasn't tagged a release past v0.12.0, so a normal go get -u won't pick it up yet.
Once go-nvlib cuts a release with #108 in it, or if a pseudo-version pin to the merge commit a9dc4f8 works as a stopgap, this repo's go.mod and vendor tree need the bump. nvidia-container-toolkit vendors the same broken copy directly (filed as NVIDIA/nvidia-container-toolkit#1966), and this repo pulls it in a second time through that module.
Closed issue: NVIDIA/go-nvlib#107
Merged fix: NVIDIA/go-nvlib#108
Same issue in nvidia-container-toolkit: NVIDIA/nvidia-container-toolkit#1966
I can open the dependency bump PR once a release or pseudo-version is agreed on.