On Mon, 2024-06-24 at 11:28 +0200, Andreas Beckmann wrote: > On 22/06/2024 10.46, Adam D. Barratt wrote: > > On Sat, 2024-06-22 at 01:10 +0200, Andreas Beckmann wrote: > > > On 21/06/2024 19.05, Adam D. Barratt wrote: > > > > On Tue, 2024-06-11 at 02:02 +0200, Andreas Beckmann wrote: > > > > > A new upstream release of the nvidia drivers in non-free is > > > > > needed > > > > > for fixing a few new CVEs. > > > > > > > > The ppc64el build failed: > > > > > > > > FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only > > > > symbol 'rcu_read_unlock_strict' > > > > make[5]: *** [/usr/src/linux-headers-5.10.0-30- > > > > common/scripts/Makefile.modpost:123: /<<PKGBUILDDIR>>/kernel- > > > > source-tree/Module.symvers] Error 1 > > > > > > OK, I can reproduce that with linux-headers-5.10.0-30-powerpc64le > > > but > > > not with linux-headers-5.10.0-28-powerpc64le (nor with > > > linux-headers-6.8.12-powerpc64le) > > > > "Yay". > > This happened: > > There are two commits in 6.8 that modify (the arch independent) > pfn_valid() in include/linux/mmzone.h to fix race conditions: > > 5ec8e8ea8b7783fab150cf86404fc38cb4db8800 (v6.8-rc1) > introduces usage of rcu_read_lock()/rcu_read_unlock() > (which are (transitively) GPL-only symbols) > > f6564fce256a3944aa1bc76cb3c40e792d97c1eb (v6.8-rc3) > switches that to rcu_read_lock_sched()/rcu_read_unlock_sched() > (which are not) > > Both commits got backported to Linux 6.1 (in bookworm) in > v6.1.76/v6.1.77 but so far only the first got backported to Linux > 5.10 (in bullseye) in v5.10.210. > I just filed #1074170 for the potentially missing backport in the > bullseye-pu kernel. > > While the nvidia driver stopped using pfn_valid() in 470.239.06, it > still uses the (arch specific) virt_addr_valid() macro. > > On ppc64el (arch/powerpc/include/asm/page.h) this macro calls the > arch independent pfn_valid() (which is transitively GPL-only). > > On amd64 (arch/x86/include/asm/page.h) this macro uses > EXPORT_SYMBOL(__virt_addr_valid) from arch/x86/mm/physaddr.c > > On arm64 (arch/arm64/include/asm/memory.h) this macro calls the arch > specific pfn_valid() (due to CONFIG_HAVE_ARCH_PFN_VALID=y). > > I'm adding a patch that (on ppc64el only) for Linux >= 5.10.210 && > Linux < 5.11 introduces nv_pfn_valid() which is the pfn_valid() from > 5.10.210 + the changes from f6564fce256a3944aa1bc76cb3c40e792d97c1eb > as well as nv_virt_addr_valid() which uses it. > > It has only slightly been tested: > - building a module for linux-headers-5.10.0-30-powerpc64le now > succeeds > - building a module for linux-headers-5.10.0-28-powerpc64le > (5.10.209) > still succeeds > - building a module for linux-headers-5.10.0-30-amd64 still succeeds > (patch is theoretically a no-op on amd64) > - untested on arm64, but patch is theoretically a no-op on arm64 > > I'm not routing this patch through sid and bookworm for now, > therefore the versions of the bullseye uploads (just done) are > - nvidia-graphics-drivers 470.256.02-2 > - nvidia-graphics-drivers-tesla-470 470.256.02-1~deb11u2 > Do you need separate opu requests for these?
Nope, as they're regression fixes to the versions currently in (o-)p-u, that's not required. It looks like the -2 update has fixed the issues on ppc64el at least; thanks. Regards, Adam
