nvidia-390xx AUR package discussion thread

seth · 2025-05-09 18:27:33

seth also wrote:

monitor the nvidia-390xx-dkms package for gcc15 patch

It's already slushing around and you don't need a patch for the 6.15 kernel - in doubt you'd likely be better off holding out on the LTS kernel and the 390xx drivers (performance-wise)

aldolat · 2025-05-09 19:14:16

An update regarding my post here: I successfully compiled and installed the nvidia-390-dkms package adding the gcc-15.patch of bufferunderrun here to PKGBUILD. Then I re-enabled the updates for:

linux
linux-headers
gcc
gcc-libs

and updated the whole system without any error.

drankinatty · 2025-05-11 02:15:00

@Seth, the Nvidia-390xx fix build with kernel 6.3 patch looks exactly like what will be required. I wonder why the AUR 390xx driver never fully incorporated that patch?

In the current kernel-6.3.patch for the AUR 390xx driver, kernel/comon/inc/nv-mm.h is never modified. This will take some significant testing to see if we can now incorporate the missing items of the 6.3 patch and make that work with the changes needed for 6.15. If we can, then the backport of Joan's 470 patch with vm_flags_reset(vma, vma->vm_flags | flags) can be directly incorporated.

When 6.15 appears, we see if it will build as is, but I suspect these inconsistencies will need to be ironed out. Has anyone tried incorporating the complete linked 6.3 kernel patch yet with the current or LTS kernel?

Last edited by drankinatty (2025-05-11 03:26:57)

canolucas · 2025-05-13 02:03:49

I'm taking a look at the linux-6.3.patch that was uploaded to the AUR package. Looks like almost all changes of the PLD Linux patch are included in our Archlinux patch

The difference is that the PLD Linux patch adds the following functions:

++static inline void nv_vm_flags_set(struct vm_area_struct *vma, vm_flags_t flags)
++{
++#if defined(NV_VM_AREA_STRUCT_HAS_CONST_VM_FLAGS)
++    vm_flags_set(vma, flags);
++#else
++    vma->vm_flags |= flags;
++#endif
++}
++
++static inline void nv_vm_flags_clear(struct vm_area_struct *vma, vm_flags_t flags)
++{
++#if defined(NV_VM_AREA_STRUCT_HAS_CONST_VM_FLAGS)
++    vm_flags_clear(vma, flags);
++#else
++    vma->vm_flags &= ~flags;
++#endif
++}

But looks like we added similar functions in nv-linux.h (first file modified in the Archlinux patch)

+#if LINUX_VERSION_CODE < KERNEL_VERSION(6, 3, 0)
+// Rel. commit "mm: introduce vma->vm_flags wrapper functions" (Suren Baghdasaryan, 26 Jan 2023)
+static inline void vm_flags_set(struct vm_area_struct *vma, vm_flags_t flags)
+{
+    vma->vm_flags |= flags;
+}
+
+static inline void vm_flags_clear(struct vm_area_struct *vma, vm_flags_t flags)
+{
+    vma->vm_flags &= ~flags;
+}
+#endif
+

As I could see in the archlinux patch, our approach is different. Instead of using the wrapper functions that start with nv_, we are using the functions defined in Linux kernel directly, (we just declare the functions if the kernel version is < 6.3).

I think we were functionally covered. Functionally, it looks like our code didn't differ from Joan's source code. Yes, the name of the wrapper functions differ vm_flags_set vs nv_vm_flags_set, vm_flags_clear vs vm_flags_clear but both pairs of wrapper functions just add or remove the given flags vma->vm_flags |= flags and vma->vm_flags &= ~flags respectively.

So, what will be the problem with the upcoming Linux kernel release ? I don't see too much code breakage. Yes, Joan's 6.15 patch rely on the functions named nv_vm_flags_set and nv_vm_flags_unset being present. But what if we continue using the functions already defined in the Linux kernel directly (vm_flags_set and vm_flags_clear) ?

I agree that we will be better off avoiding this difference with Joan's code. We'll probably face more merge conflicts or breakage in the future, and being Joan the main maintainer regarding the compatibility of this old driver with new kernel versions, I agree that we will be better off being sync'ed with Joans' codebase.

nv_ wrapper functions also give us more flexibility, we will be able to handle compatibility issues in our package, instead of relying on the Linux kernel functions and being affected by possible changes there.

On the other hand, Joans' changes to the nv_vm_flags_set and nv_vm_flags_clear functions (previously created by him in the 6.3 patch) is just a licence thing, maybe it is not really needed at all. We will have to see when the next kernel version gets released.

static inline void nv_vm_flags_set(struct vm_area_struct *vma, vm_flags_t flags)
 {
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 15, 0)
+    // Rel. commit "mm: uninline the main body of vma_start_write()" (Suren Baghdasaryan, 13 Feb 2025)
+    // Since Linux 6.15, vm_flags_set and vm_flags_clear call a GPL-only symbol
+    // for locking (__vma_start_write), which can't be called from non-GPL code.
+    // However, it appears all uses on the driver are on VMAs being initially
+    // mapped / which are already locked, so we can use vm_flags_reset, which
+    // doesn't lock the VMA, but rather just asserts it is already write-locked.
+    vm_flags_reset(vma, vma->vm_flags | flags);
+#else
     vm_flags_set(vma, flags);
+#endif
 }
 
 static inline void nv_vm_flags_clear(struct vm_area_struct *vma, vm_flags_t flags)
 {
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 15, 0)
+    // Rel. commit "mm: uninline the main body of vma_start_write()" (Suren Baghdasaryan, 13 Feb 2025)
+    // See above
+    vm_flags_reset(vma, vma->vm_flags & ~flags);
+#else
     vm_flags_clear(vma, flags);
+#endif
 }

EDIT: yup, looks like we will need Joan's code. symbols that are exported with EXPORT_GPL_ONLY, are only available if the kernel module contains MODULE_LICENSE("GPL")

Last edited by canolucas (2025-05-13 03:14:46)

Arch Linux

#176 2025-05-09 18:27:33

Re: nvidia-390xx AUR package discussion thread

#177 2025-05-09 19:14:16

Re: nvidia-390xx AUR package discussion thread

#178 2025-05-11 02:15:00

Re: nvidia-390xx AUR package discussion thread

#179 2025-05-13 02:03:49

Re: nvidia-390xx AUR package discussion thread

Board footer