A recorded FreeBSD/i915 buffer lifetime showed a still-live graphics buffer losing its original nonzero backing contents across page retirement and reacquisition. Replacement backing was zero-filled before a later submission. Source analysis identifies a path that transfers pages out of the original shmem object. The recorded loss is consistent with that ownership transfer; exact GPU instruction fetch and a matched single-change causal comparison have not been established.
On my Intel Meteor Lake laptop, my experience with large LAN downloads has been:
- Non-PFN kernels with my manual ZFS ARC cap removed: I have experienced a recoverable GPU hang in every attempt, using either Sway or Plasma.
- Non-PFN kernels with the 4 GiB ARC cap: I have not experienced this hang under that usage pattern.
- PFN kernels with my manual ARC cap removed: I have not experienced this hang under the same general usage pattern.
These are my personal observations. I have not supplied a formal trial count or performed a matched, single-change kernel comparison. The first result describes all of my attempts, not a universal 100% failure probability. The affected desktop can be recovered by terminating the compositor; these failures are not kernel panics. Here, "uncapped ARC" means automatic ARC sizing with a finite effective maximum.
The cap comparison supports memory reclamation or its timing as a possible condition exposing the ownership defect. There is a concrete source-level route: FreeBSD low-memory notifications invoke registered LinuxKPI shrinkers; the i915 shrinker can release eligible graphics-buffer pages. FreeBSD's ARC implementation also responds to low-memory notifications. A larger resident ARC can leave less immediately available memory and change the demand for reclaim. This is a plausible route from the cache-size difference to a buffer release, not a recorded call trace identifying the caller that released the affected buffer.
The capture established that a still-live buffer's nonzero backing page was retired and the same logical buffer later acquired zero-filled replacement backing before submission. It did not require an operation that overwrote the old physical page with zeros. The source-level ownership transfer is consistent with loss of recoverable contents across that transition. The working explanation is that the 4 GiB cap avoids or changes the problematic release/reacquisition sequence in my workload, while the PFN change preserves backing ownership when that sequence occurs. The cap does not repair the ownership logic.
The caller that initiated this buffer's release remains unidentified, and the GPU's subsequent instruction fetch was not observed. The later ARC/VM sample in
, including no recorded swap I/O and free pages above the target, does not reconstruct conditions at retirement or exclude earlier reclamation. I have used "memory pressure" informally; neither the downloads nor that later sample establish its precise state at the content-loss transition.Preserve managed OBJT_SWAP/shmem pages in their backing object and supply exclusively busy pages through an external device-pager handoff. Retain references to tracked backing owners until VMA teardown, consume each handed-off page once, and invalidate mappings without removing supported pages from their original backing object. The change also balances temporary requested-page holds, delays their publication until the required operations succeed, and rejects selecting a page already held by the same population transaction.
The pager interface makes memory-locking behavior explicit. Managed LinuxKPI IO/PFN mappings opt into a user-wiring exemption before object publication. Ordinary mappings retain their locking requirements. Kernel-origin wiring retains its separate requirements, and conservative resource-limit admission and RACCT reservations still apply. The manual changes document this policy and correct an inherited statement about per-process limits.
The patch is a candidate correction for the observed managed-shmem path. Other managed backing-owner types retain legacy transfer behavior. Invalidation covers tracked owner intervals and can revoke aliases beyond the requested VMA subrange. References to previously used owners remain until VMA teardown. Review is requested on these lifetime, invalidation, pager-interface and memory-locking decisions.
The source patch contains the PFN/VM changes, their manuals, and a kernel interface version marker. Local diagnostic instrumentation and unrelated laptop changes are excluded. Kernel/module pager interfaces change and require compatible kernel and module builds.
The __FreeBSD_version bump from 1600024 to 1600025 is provisional for this review. The accepting committer must confirm or adjust the final number against the landing tree and add the corresponding Porter's Handbook version entry with the actual commit identity. This review does not reserve an official version number. The manual pages retain their base dates until merge.
Related work
- D32090 already discussed the risk of shared-memory contents being lost when pages move between objects. This submission makes no claim to have first identified that hazard.
- drm-kmod issue 481 and Bugzilla 296448 report related PFN insertion failures. The proposed mapped-page handling change in issue 481 still removes pages from their original object, and subsequent feedback reports rendering corruption and GPU hangs. Whether those reports contain the exact locally recorded lifetime failure remains unverified.
- drm-kmod PR 484 questions the existing ownership model and proposes exporter-provided VM objects for dma-buf mmap, primarily for udmabuf. That is relevant design work with which this proposal may need coordination.
The public-source comparison has not established an equivalent implementation or the absence of one. Direction toward an existing review or preferred mapping design would be welcome.
This patch and supporting analysis were developed with AI assistance. Independent maintainer review of the implementation and design is requested.