In D58762#1348310, @emaste wrote:

I don't think we use large pages in linuxkpi. Therefore, this new function is curently a no-op.

Is there a way we can add either a compile-time error or KASSERT to ensure this remains the case?

No objections from me reading this. Wait what others are saying.

For what it's there it is fine.

I am splitting it up into fwget and the shell script so I can MFC fwget quickly more easily) and am committing this.
Sorry it fell through the cracks after your last update.

Unless there will be objections I'll put this in by Tuesday evening.

We have a bug report for this problem now (this review seems to solve it).
Here's the end of the thread on current: https://lists.freebsd.org/archives/freebsd-current/2026-July/010533.html

Update linux_free_pages() as suggested by @dumbbell.

In D58320#1341094, @dumbbell wrote:

I made an inline comment in linux_free_page(): there is a refcounting issue vs. the call to lkpi_page_unset_vm_page().

Beside this issue, I also made the following change to the i915 DRM driver which manipulates vm_page_t directly:

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 2d94542f4d..58f64e9c0e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -171,14 +171,21 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
 		if (vm_object_set_memattr(vmobj, VM_MEMATTR_WRITE_COMBINING) != KERN_SUCCESS) {
 #if __FreeBSD_version >= 1500038
 			struct pctrie_iter pages;
-			vm_page_t page;
+			struct vm_page *m;
 
 			vm_page_iter_init(&pages, vmobj);
-			VM_RADIX_FORALL(page, &pages)
+			VM_RADIX_FORALL(m, &pages)
 #else
-			for (vm_page_t page = vm_page_find_least(vmobj, 0); page != NULL; page = vm_page_next(page))
+			for (vm_page_t m = vm_page_find_least(vmobj, 0); m != NULL; m = vm_page_next(m))
 #endif
-				pmap_page_set_memattr(page, VM_MEMATTR_WRITE_COMBINING);
+			{
+#ifdef PAGE_IS_LKPI_PAGE
+				struct page *page;
+				page = lkpi_vm_page_to_page(m);
+				lkpi_page_set_vm_page(page, m);
+#endif
+				pmap_page_set_memattr(m, VM_MEMATTR_WRITE_COMBINING);
+			}
 		}
 		VM_OBJECT_WUNLOCK(vmobj);
 	}

Do you think it's fine?

In D58320#1341094, @dumbbell wrote:

I made an inline comment in linux_free_page(): there is a refcounting issue vs. the call to lkpi_page_unset_vm_page().

Beside this issue, I also made the following change to the i915 DRM driver which manipulates vm_page_t directly:

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 2d94542f4d..58f64e9c0e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -171,14 +171,21 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
 		if (vm_object_set_memattr(vmobj, VM_MEMATTR_WRITE_COMBINING) != KERN_SUCCESS) {
 #if __FreeBSD_version >= 1500038
 			struct pctrie_iter pages;
-			vm_page_t page;
+			struct vm_page *m;
 
 			vm_page_iter_init(&pages, vmobj);
-			VM_RADIX_FORALL(page, &pages)
+			VM_RADIX_FORALL(m, &pages)
 #else
-			for (vm_page_t page = vm_page_find_least(vmobj, 0); page != NULL; page = vm_page_next(page))
+			for (vm_page_t m = vm_page_find_least(vmobj, 0); m != NULL; m = vm_page_next(m))
 #endif
-				pmap_page_set_memattr(page, VM_MEMATTR_WRITE_COMBINING);
+			{
+#ifdef PAGE_IS_LKPI_PAGE
+				struct page *page;
+				page = lkpi_vm_page_to_page(m);
+				lkpi_page_set_vm_page(page, m);
+#endif
+				pmap_page_set_memattr(m, VM_MEMATTR_WRITE_COMBINING);
+			}
 		}
 		VM_OBJECT_WUNLOCK(vmobj);
 	}

Do you think it's fine?

In D55035#1341066, @aokblast wrote:

In D55035#1341051, @bz wrote:

Thanks for the comment; I have a way larger branch I think than what is in review. Do you want to have a look at the entire bits? I'd be thrilled if someone will review them :) and more than happy to extract the next days.

Do you mean https://reviews.freebsd.org/D54987? I was typing something while you leave your comment:)

In D58448#1341087, @ngie wrote:

In D58448#1340980, @bz wrote:

The module is not built at all so I wonder if you actually built it with mfsbsd.

I have other outstanding diffs on a branch which are required to get brcm to build/install: https://github.com/ngie-eign/freebsd-src/tree/brcm-polish . I'm trying to get a working driver on my mid-2010s MacBooks.

Thanks for the comment; I have a way larger branch I think than what is in review. Do you want to have a look at the entire bits? I'd be thrilled if someone will review them :) and more than happy to extract the next days.

The fact that there was a different behaviour with the extra bool means there was a reason for this.
We cannot unconditionally clear this and change behaviour as we still support Linux 6.1-lts drm-kmod and others.
This will need more careful investigation.

I would say "NO". The idea is to keep the #ifdef portion minimal as most of the differences will have to be upstreamed one day. Keeping the #ifdef away from the next statement makes merging easier.

The module is not built at all so I wonder if you actually built it with mfsbsd.

In D58299#1339700, @emaste wrote:

Sure. I think they could just stay where they are until the refactor but OK.

Anyone on this one?

This will go in by Friday.

This will go in by Friday.

This will go in by Friday.

@markj @kib did I get the last version right?

This will go in by Friday.

Making this an inline function for the point of making it a function seems hard to justify for single use code.
Can we at least keep it as a normal function in ioctl.c?

Updated version at https://reviews.freebsd.org/D58320

REbase in the hope that with this the stack applies cleanly as well.

In D58306#1337381, @bnovkov wrote:

In D58306#1337245, @bz wrote:

Please see the wireless mailing list where I sent a patch for test and did not get feedback. Changing the driver is the wrong thing to do (not that it works well currently).

https://lists.freebsd.org/archives/freebsd-wireless/2026-July/004328.html

Ah, I wasn't aware of your patch, thanks for pointing this out.
FWIW your patch fixes the message spam on my machine.
I'll abandon this revision so please feel free to commit the patch you proposed.

Please see the wireless mailing list where I sent a patch for test and did not get feedback. Changing the driver is the wrong thing to do (not that it works well currently).

Properly nest calls.

In D58298#1337045, @kib wrote:

For the discussion, I am still somewhat surprised that so much of the FreeBSD symbols are leaked into linuxkpi headers, Most amusing and dangerous is PAGE_MASK (AFAIR).