Because an LLM wrote the patch, summary, and test plan, you can see things such as "The user reports", instead of "I noticed" while reading all this stuff.

It is really a lot of work to try and understand the review description. Let's please try to simplify the description of what's going on.

It sounds like the i915 GEM shrinker is reclaiming pages from a shared memory object which backs a GEM object, and this is happening while the GPU is actively working on the object. Is that right? Can you please point to the exact code paths where this happens? I would naively expect that i915 or DRM somehow pins active objects, precisely to avoid this problem, so we will have to understand why that isn't working.

If my understand is wrong, then please try to succinctly explain what is going on, in terms of actual code being executed. Writing something like, "source analysis identifies a path that transfers pages out of the original shmem object," is very unhelpful unless you actually point to the path you're talking about.

Let me explain what happened. I noticed a problem: when ZFS ARC was automatically sized and I started downloading multi-gigabyte files over my home LAN, eventually a recoverable GPU hang would happen on either Sway or Plasma. If, for example, I downloaded around 4 or 5 multi-gigabyte files in the automatically sized ZFS ARC environment, I would get a 100% guarantee a recoverable GPU hang would happen on either Sway or Plasma. I would have to remotely kill kwin_wayland_wrapper and kwin_wayland through ssh; otherwise, the computer wouldn't be accessible directly. Sway wouldn't block direct access, but I would still have to kill it due to such hangs. When I capped ZFS ARC and repeated the file downloading experiments, GPU hangs stopped happening, so I thought the problem was resolved. However, GPU hangs returned on Sway/Plasma when an LLM I was working with started doing computationally intensive things in this capped ARC environment. I asked the LLM to explain to me the cause of these GPU hangs, and it told me I was dealing with an ownership/bookkeeping bug which caused pages to lose access to their original backing objects and that's why these GPU hangs occurred. I asked it to fix the bug, and with the code that I later posted here, I stopped experiencing GPU hangs in either automatically sized ZFS ARC combined with file downloading situations or LLM-doing-computationally-intensive-work situations. I am not really knowledgeable about computer-related stuff, so I don't know what was going on behind the scenes when the GPU hangs occurred. Maybe a memory pressure thing indirectly triggered this ownership bug. All I know is that I encountered a bug and the LLM seems to have fixed it for me.

In D59481#1370014, @oleglelchuk_gmail.com wrote:

Let me explain what happened. I noticed a problem: when ZFS ARC was automatically sized and I started downloading multi-gigabyte files over my home LAN, eventually a recoverable GPU hang would happen on either Sway or Plasma. If, for example, I downloaded around 4 or 5 multi-gigabyte files in the automatically sized ZFS ARC environment, I would get a 100% guarantee a recoverable GPU hang would happen on either Sway or Plasma. I would have to remotely kill kwin_wayland_wrapper and kwin_wayland through ssh; otherwise, the computer wouldn't be accessible directly. Sway wouldn't block direct access, but I would still have to kill it due to such hangs. When I capped ZFS ARC and repeated the file downloading experiments, GPU hangs stopped happening, so I thought the problem was resolved. However, GPU hangs returned on Sway/Plasma when an LLM I was working with started doing computationally intensive things in this capped ARC environment. I asked the LLM to explain to me the cause of these GPU hangs, and it told me I was dealing with an ownership/bookkeeping bug which caused pages to lose access to their original backing objects and that's why these GPU hangs occurred. I asked it to fix the bug, and with the code that I later posted here, I stopped experiencing GPU hangs in either automatically sized ZFS ARC combined with file downloading situations or LLM-doing-computationally-intensive-work situations. I am not really knowledgeable about computer-related stuff, so I don't know what was going on behind the scenes when the GPU hangs occurred. Maybe a memory pressure thing indirectly triggered this ownership bug. All I know is that I encountered a bug and the LLM seems to have fixed it for me.

The problem is that we will not apply this patch without understanding exactly what it is doing, and it is very hard to understand what it is doing without understanding the problem it fixes. So to make progress, we will need more details about the problem, as I asked for. It may be that the underlying bug can be fixed with a two-line patch instead of the one the LLM generated.

Not quite. Since my last comment, I reproduced the hang with an unmodified
FreeBSD main GENERIC kernel at 7f8feee5ab922e6645f4061e9ca29109411aadef
and unmodified drm-kmod at 1d04976c1870bce01094b78e46c48f6eab810867.
With the LLM's assistance, I also collected a live DTrace recording. It does
not show the shrinker reclaiming pages while the GPU is actively using them.
__i915_gem_object_put_pages() refuses an object whose backing pages are
pinned. The problem is that an earlier FreeBSD PFN mmap changes the ownership
of the pages, so a later legitimate page release can destroy backing that i915
expects shmem to retain.

The mapping path is:

i915_gem_object_mmap()
  -> vm_fault_cpu()
  -> remap_io_sg()
  -> remap_sg()
  -> lkpi_vmf_insert_pfn_prot_locked()

vm_fault_cpu() pins the GEM object's shmem-backed scatter/gather pages while
calling remap_io_sg(). On Linux, remap_sg() installs a special PFN PTE and
leaves the page owned by shmem. On FreeBSD it calls
lkpi_vmf_insert_pfn_prot_locked(). For every managed page still belonging to
the shmem OBJT_SWAP object, that function calls
vm_pager_page_unswapped(page), vm_page_remove(page), and then
vm_page_iter_insert(page, vm_obj, pindex, ...). This discards the page's swap
backing, removes it from shmem, and inserts the physical page into the mmap's
OBJT_MGTDEVICE object. The exact implementation is
[linux_page.c:508-575](https://github.com/freebsd/freebsd-src/blob/7f8feee5ab922e6645f4061e9ca29109411aadef/sys/compat/linuxkpi/common/src/linux_page.c#L508-L575),
called by
[i915_mm.c:89-115](https://github.com/freebsd/drm-kmod/blob/1d04976c1870bce01094b78e46c48f6eab810867/drivers/gpu/drm/i915/i915_mm.c#L89-L115).

During reclaim, FreeBSD's
[linuxkpi_vm_lowmem()](https://github.com/freebsd/freebsd-src/blob/7f8feee5ab922e6645f4061e9ca29109411aadef/sys/compat/linuxkpi/common/src/linux_shrinker.c#L99-L142)
invokes i915's shrinker. i915 selects a releasable object and calls
__i915_gem_object_put_pages()
([i915_gem_shrinker.c:175-230](https://github.com/freebsd/drm-kmod/blob/1d04976c1870bce01094b78e46c48f6eab810867/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c#L175-L230)).
That function checks for pinned pages, revokes the mmap, unsets the pages, and
calls the shmem put-pages callback
([i915_gem_pages.c:239-267](https://github.com/freebsd/drm-kmod/blob/1d04976c1870bce01094b78e46c48f6eab810867/drivers/gpu/drm/i915/gem/i915_gem_pages.c#L239-L267)).
Once VMA invalidation or pager teardown removes a page from the temporary
OBJT_MGTDEVICE object, it is objectless because PFN insertion already removed
it from shmem. When shmem_sg_free_table() drops the last wire, an objectless
page with raw ref_count == 1 enters vm_page_free_toq(). The original shmem
slot now has neither a resident page nor swap backing. A later
linux_shmem_read_mapping_page_gfp() for that offset must create replacement
backing rather than recover the original graphics-buffer bytes. Thus the object
can be correctly inactive and unpinned when reclaimed, yet still be alive and
expected to retain contents for later use.

The DTrace run recorded 3,151 PFN insertions from a short vkcube trigger. All
3,151 entered swap_pager_unswapped, were removed from their source objects,
and were inserted into the target pager object. On release, 70 pages were
unwired; 64 were objectless with raw ref_count == 1, and exactly those 64
entered vm_page_free_toq(). The trace also observed four
__i915_gem_object_put_pages() calls in pagedaemon. The program and raw
aggregate output are attached as

In the clean Sway reproduction, ARC grew to about 11.91 GiB, free memory reached
the VM reclaim boundary, and ARC reclaim began. Sway stopped responding, then
the render engine reported GPU HANG: ecode 12:1:85dff5fb, in sway three
seconds later. This supports ARC growth as the condition that invokes reclaim;
ARC itself is not modifying the graphics buffer.

I have not identified the exact Sway buffer from its original contents through
reclaim to the stalled GPU submission, and I have not yet performed a matched
run changing only this fix. The ownership-loss lifecycle itself was observed
directly, while the final buffer-to-hang link remains strongly supported rather
than fully proved. A smaller fix may be possible; I am not claiming that the
current twelve-file implementation is minimal. The required semantic change is
to map these managed pages without removing them from their shmem backing object
or discarding that object's backing information.

I think I understand what is going on.

Long time ago, when I first ported the GEM infrastructure from Linux to FreeBSD, I remember that the principle was that the given page can exists only in single domain (this is not same as NUMA proximity domain, but like CPU-cached or GPU-cached indicator). The GPU L1/L2 were not coherent with the CPU L1/L2, and each domain change of the page required explicit handling of the cache. This is why the pmap_invalidate_cache_pages() was added which cannot rely on the self-snoop capability of (Intel) CPUs.

Now, I believe that Intel GPUs grown the coherent L3 between CPU and GPU, and L1/L2 caches are at least invalidated when cache line crosses domain. GPU home agent might even participate in the MESI as another coherent device, but this is not important for us. What is important is that it seems to be valid for page to be both accessed by CPU and GPU, effectively making the page existing in both CPU and GPU caching domains simultaneously.

The object' ownership model for pages cannot easily model that. I suspect we have to do something weird like allowing fake pages to exists in the swap objects. So for instance when lkpi_vmf_insert_pfn_prot_locked() observes that page->object != vma->object, and page->object is the managed device pager, then instead of removing the page from the page->object, we keep it there but install a fake page into vma->object. Then something special would have to be done for pageout when it observes such page (skip), and perhaps in dozen other places which are not ready to find non-fictious pages in the swap objects.

Please add 'alc' to the reviewers.

In D59481#1370433, @kib wrote:

I think I understand what is going on.

Long time ago, when I first ported the GEM infrastructure from Linux to FreeBSD, I remember that the principle was that the given page can exists only in single domain (this is not same as NUMA proximity domain, but like CPU-cached or GPU-cached indicator). The GPU L1/L2 were not coherent with the CPU L1/L2, and each domain change of the page required explicit handling of the cache. This is why the pmap_invalidate_cache_pages() was added which cannot rely on the self-snoop capability of (Intel) CPUs.

Now, I believe that Intel GPUs grown the coherent L3 between CPU and GPU, and L1/L2 caches are at least invalidated when cache line crosses domain. GPU home agent might even participate in the MESI as another coherent device, but this is not important for us. What is important is that it seems to be valid for page to be both accessed by CPU and GPU, effectively making the page existing in both CPU and GPU caching domains simultaneously.

The object' ownership model for pages cannot easily model that. I suspect we have to do something weird like allowing fake pages to exists in the swap objects. So for instance when lkpi_vmf_insert_pfn_prot_locked() observes that page->object != vma->object, and page->object is the managed device pager, then instead of removing the page from the page->object, we keep it there but install a fake page into vma->object. Then something special would have to be done for pageout when it observes such page (skip), and perhaps in dozen other places which are not ready to find non-fictious pages in the swap objects.

My fuzzy understanding of the code is that lkpi_vmf_insert_pfn_prot_locked() is moving pages from the shmem object to the MGTDEVICE object. In that case it sounds like it should instead 1) allocate a fake page with the same paddr and insert it into the MGTDEVICE object, and 2) wire the source page.

If userspace wishes to map GPU memory into CPU page tables, then presumably it can map a MGTDEVICE directly? That is, there is no need to move a page from MGTDEVICE->SWAP.

In D59481#1370542, @markj wrote:

In D59481#1370433, @kib wrote:

I think I understand what is going on.

Long time ago, when I first ported the GEM infrastructure from Linux to FreeBSD, I remember that the principle was that the given page can exists only in single domain (this is not same as NUMA proximity domain, but like CPU-cached or GPU-cached indicator). The GPU L1/L2 were not coherent with the CPU L1/L2, and each domain change of the page required explicit handling of the cache. This is why the pmap_invalidate_cache_pages() was added which cannot rely on the self-snoop capability of (Intel) CPUs.

Now, I believe that Intel GPUs grown the coherent L3 between CPU and GPU, and L1/L2 caches are at least invalidated when cache line crosses domain. GPU home agent might even participate in the MESI as another coherent device, but this is not important for us. What is important is that it seems to be valid for page to be both accessed by CPU and GPU, effectively making the page existing in both CPU and GPU caching domains simultaneously.

The object' ownership model for pages cannot easily model that. I suspect we have to do something weird like allowing fake pages to exists in the swap objects. So for instance when lkpi_vmf_insert_pfn_prot_locked() observes that page->object != vma->object, and page->object is the managed device pager, then instead of removing the page from the page->object, we keep it there but install a fake page into vma->object. Then something special would have to be done for pageout when it observes such page (skip), and perhaps in dozen other places which are not ready to find non-fictious pages in the swap objects.

My fuzzy understanding of the code is that lkpi_vmf_insert_pfn_prot_locked() is moving pages from the shmem object to the MGTDEVICE object. In that case it sounds like it should instead 1) allocate a fake page with the same paddr and insert it into the MGTDEVICE object, and 2) wire the source page.

If userspace wishes to map GPU memory into CPU page tables, then presumably it can map a MGTDEVICE directly? That is, there is no need to move a page from MGTDEVICE->SWAP.

I do not think the direction matters. In particular, wiring the source swap-backed page does not help: when would it be unwired? What prevents the source swap object from termination?

In D59481#1371356, @kib wrote:

In D59481#1370542, @markj wrote:

In D59481#1370433, @kib wrote:

I think I understand what is going on.

Long time ago, when I first ported the GEM infrastructure from Linux to FreeBSD, I remember that the principle was that the given page can exists only in single domain (this is not same as NUMA proximity domain, but like CPU-cached or GPU-cached indicator). The GPU L1/L2 were not coherent with the CPU L1/L2, and each domain change of the page required explicit handling of the cache. This is why the pmap_invalidate_cache_pages() was added which cannot rely on the self-snoop capability of (Intel) CPUs.

Now, I believe that Intel GPUs grown the coherent L3 between CPU and GPU, and L1/L2 caches are at least invalidated when cache line crosses domain. GPU home agent might even participate in the MESI as another coherent device, but this is not important for us. What is important is that it seems to be valid for page to be both accessed by CPU and GPU, effectively making the page existing in both CPU and GPU caching domains simultaneously.

The object' ownership model for pages cannot easily model that. I suspect we have to do something weird like allowing fake pages to exists in the swap objects. So for instance when lkpi_vmf_insert_pfn_prot_locked() observes that page->object != vma->object, and page->object is the managed device pager, then instead of removing the page from the page->object, we keep it there but install a fake page into vma->object. Then something special would have to be done for pageout when it observes such page (skip), and perhaps in dozen other places which are not ready to find non-fictious pages in the swap objects.

My fuzzy understanding of the code is that lkpi_vmf_insert_pfn_prot_locked() is moving pages from the shmem object to the MGTDEVICE object. In that case it sounds like it should instead 1) allocate a fake page with the same paddr and insert it into the MGTDEVICE object, and 2) wire the source page.

If userspace wishes to map GPU memory into CPU page tables, then presumably it can map a MGTDEVICE directly? That is, there is no need to move a page from MGTDEVICE->SWAP.

I do not think the direction matters. In particular, wiring the source swap-backed page does not help: when would it be unwired?

When the driver knows that the GPU is no longer mapping the pages. In fact it already implements this mechanism: each GEM object type provides get_pages, which prepares the object's backing pages to be mapped into the GTT. For shmem objects, this is implemented by shmem_get_pages() -> shmem_sg_alloc_table() -> shmem_read_folio_gfp() -> vm_page_grab_valid(VM_ALLOC_WIRED).

The problem is with the implementation of lkpi_vmf_insert_pfn_prot_locked(): it moves pages out of the shmem object, so a subsequent vm_page_grab will not see moved pages, and it will allocate and zero-fill new ones. remap_pfn() and remap_sg() in i915 should be allocating fake pages instead of moving pages between objects.

What prevents the source swap object from termination?

Why does it matter? Even if the object is terminated (I would expect the driver to prevent this), wired pages will not be freed.

The technical language that you guys are using is above my head. I take it that you guys now understand the nature of the bug, so I'll just move out of your way and let you fix it. Thank you in advance for the fix! I don't understand though why no one else reported the bug before I did it myself: doesn't a regular Joe who uses Sway/Plasma often want to download files over his home LAN without changing the default "automatically sized ZFS ARC" setting first? He doesn't need to change this setting because he has no idea in the first place it needs to be changed.

In D59481#1371497, @markj wrote:

In D59481#1371356, @kib wrote:

In D59481#1370542, @markj wrote:

In D59481#1370433, @kib wrote:

I think I understand what is going on.

Long time ago, when I first ported the GEM infrastructure from Linux to FreeBSD, I remember that the principle was that the given page can exists only in single domain (this is not same as NUMA proximity domain, but like CPU-cached or GPU-cached indicator). The GPU L1/L2 were not coherent with the CPU L1/L2, and each domain change of the page required explicit handling of the cache. This is why the pmap_invalidate_cache_pages() was added which cannot rely on the self-snoop capability of (Intel) CPUs.

Now, I believe that Intel GPUs grown the coherent L3 between CPU and GPU, and L1/L2 caches are at least invalidated when cache line crosses domain. GPU home agent might even participate in the MESI as another coherent device, but this is not important for us. What is important is that it seems to be valid for page to be both accessed by CPU and GPU, effectively making the page existing in both CPU and GPU caching domains simultaneously.

The object' ownership model for pages cannot easily model that. I suspect we have to do something weird like allowing fake pages to exists in the swap objects. So for instance when lkpi_vmf_insert_pfn_prot_locked() observes that page->object != vma->object, and page->object is the managed device pager, then instead of removing the page from the page->object, we keep it there but install a fake page into vma->object. Then something special would have to be done for pageout when it observes such page (skip), and perhaps in dozen other places which are not ready to find non-fictious pages in the swap objects.

My fuzzy understanding of the code is that lkpi_vmf_insert_pfn_prot_locked() is moving pages from the shmem object to the MGTDEVICE object. In that case it sounds like it should instead 1) allocate a fake page with the same paddr and insert it into the MGTDEVICE object, and 2) wire the source page.

If userspace wishes to map GPU memory into CPU page tables, then presumably it can map a MGTDEVICE directly? That is, there is no need to move a page from MGTDEVICE->SWAP.

I do not think the direction matters. In particular, wiring the source swap-backed page does not help: when would it be unwired?

When the driver knows that the GPU is no longer mapping the pages. In fact it already implements this mechanism: each GEM object type provides get_pages, which prepares the object's backing pages to be mapped into the GTT. For shmem objects, this is implemented by shmem_get_pages() -> shmem_sg_alloc_table() -> shmem_read_folio_gfp() -> vm_page_grab_valid(VM_ALLOC_WIRED).

The problem is with the implementation of lkpi_vmf_insert_pfn_prot_locked(): it moves pages out of the shmem object, so a subsequent vm_page_grab will not see moved pages, and it will allocate and zero-fill new ones. remap_pfn() and remap_sg() in i915 should be allocating fake pages instead of moving pages between objects.

Might be, a fake page is probably the closest analog to the special PTE mentioned in the original linux driver sources.

What prevents the source swap object from termination?

Why does it matter? Even if the object is terminated (I would expect the driver to prevent this), wired pages will not be freed.

And the device object termination needs to unwire pages found by PHYS_TO_VM_PAGE(VM_PAGE_TO_PHYS(fake)) for each fake page owned by it?

(I may not be following, please excuse me if my assessment is incorrect)
Please stop this.
If you don't know what is going on in the patch, and cannot explain it, and use many words, also the patch is large, it is not useful and hurts.

Please file a bug report concisely explaining, in your own words, what you are observing, and what you expect to see instead.
Here are some instructions to get you started: https://freebsdfoundation.org/our-work/journal/browser-based-edition/embedded-2/writing-effective-bug-reports/

In D59481#1374253, @ziaee wrote:

(I may not be following, please excuse me if my assessment is incorrect)
Please stop this.
If you don't know what is going on in the patch, and cannot explain it, and use many words, also the patch is large, it is not useful and hurts.

Please file a bug report concisely explaining, in your own words, what you are observing, and what you expect to see instead.
Here are some instructions to get you started: https://freebsdfoundation.org/our-work/journal/browser-based-edition/embedded-2/writing-effective-bug-reports/

Hi. I was under the impression that the other folks who spoke in this space understood what the bug is. Pages that, from a user's point of view, contained valid data were mistakenly replaced by zero-filled pages; that's why GPU hangs occurred. The original patch and patch #2 fixed this GPU hang bug, but in turn, they introduced other bugs, so, hopefully, patch #3, which is the current patch, fixed those other bugs too, without introducing new bugs.

In D59481#1374287, @oleglelchuk_gmail.com wrote:

In D59481#1374253, @ziaee wrote:

(I may not be following, please excuse me if my assessment is incorrect)
Please stop this.
If you don't know what is going on in the patch, and cannot explain it, and use many words, also the patch is large, it is not useful and hurts.

Please file a bug report concisely explaining, in your own words, what you are observing, and what you expect to see instead.
Here are some instructions to get you started: https://freebsdfoundation.org/our-work/journal/browser-based-edition/embedded-2/writing-effective-bug-reports/

Hi. I was under the impression that the other folks who spoke in this space understood what the bug is. Pages that, from a user's point of view contained valid data, were mistakenly replaced by zero-filled pages; that's why GPU hangs occurred. The original patch and patch #2 fixed this GPU hang bug, but in turn, they introduced other bugs, so, hopefully, patch #3, which is the current patch, fixed those other bugs too, without introducing new bugs.

The VM folks are wrapping their heads around it and likely will figure out a much smaller, easier solution. But! You're at least exploring and trying to identify the behavioural issues, so do keep tinkering. The LLM prose may be a bit much (eg we don't need to know about your local test cases passing and such) but the dives into the code paths being executed in different situations are likely helpful here.

I prototyped something in D59883