Igt-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH i-g-t 0/2] tests/intel: Don't probe intel_allocator offsets without full-ppgtt
@ 2026-09-24 15:24 Janusz Krzysztofik
  2026-09-24 15:24 ` [PATCH i-g-t 1/2] tests/intel/gem_softpin: Skip safe-alignment " Janusz Krzysztofik
                   ` (10 more replies)
  0 siblings, 11 replies; 20+ messages in thread
From: Janusz Krzysztofik @ 2026-09-24 15:24 UTC (permalink / raw)
  To: igt-dev
  Cc: intel-gfx, Kamil Konieczny, Zbigniew Kempczyński, Andi Shyti,
	Krzysztof Karas, Sebastian Brzezinka, Krzysztof Niemiec,
	Janusz Krzysztofik

tests/intel/gem_softpin@safe-alignment has been occasionally failing
in CI with -ENOSPC, tracked as:

  https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/15527

The failure is sporadic and hardware-specific rather than
deterministic: the very same fi-hsw-4770 CI machine was observed both
failing and succeeding this subtest across different runs of
otherwise identical test lists.

Debug logging added by commit 90caf93a2a859388c10e1413594f764154f762e3
("tests/intel/gem_softpin: Show debug info also on success") to also
report the detected offset/alignment values on success, not just on
failure, showed that gem_detect_min_start_offset_for_region()
occasionally reports different values across otherwise identical runs
on the same aliasing-ppgtt hardware.

Root-caused as follows (full write-up on the work item above):
a PAGE_SIZE gap transiently opens up in the GGTT on aliasing-ppgtt
platforms right after driver probe, caused by late release of an
object pinned early for workaround validation, overlapping with an
fbdev framebuffer object pinned into the same slot right after; once
the workaround object is finally released, the gap is left behind.
gem_detect_min_start_offset_for_region() can observe that transient
gap and report it as a safe low offset, when it is in fact only
incidentally free and not reserved for our exclusive use.

That root cause, and the questions it raised about whether this
subtest belongs on integrated/aliasing-ppgtt platforms at all, led to
a closer look at gem_detect_min_start_offset_for_region(),
gem_detect_safe_start_offset() and gem_detect_safe_alignment()
(lib/i915/intel_memory_region.c). They turn out to exist for a single
purpose: bootstrapping intel_allocator's start offset and default
alignment (lib/intel_allocator.c). Every other call site in the tree
is either internal to the allocator itself or reachable only through
an active allocator handle (ahnd).

lib/intel_batchbuffer.c's __intel_bb_create() already documents why
that matters:

    If we don't have full ppgtt driver can change our addresses
    so allocator is useless in this case. Just enforce relocations
    for such gens and don't use allocator at all.

More precisely: without full-ppgtt, intel_allocator's private
placement bookkeeping isn't visible to the kernel, which remains free
to hand out addresses intel_allocator considers already reserved to
other users (under aliasing ppgtt, as observed above) or to relocate
objects on its own authority (under global gtt). Either way, values
returned by these probing helpers carry no guarantee once handed to a
plain EXEC_OBJECT_PINNED execbuf outside of an allocator-managed
context, making any test relying on them without checking
gem_uses_full_ppgtt() exercise a scenario that can't be trusted to
mean anything, and occasionally racing against unrelated kernel-owned
allocations as a result.

Auditing all call sites of the three helpers found two subtests
outside the file's already-existing full-ppgtt gated group that
called them unconditionally:

 - tests/intel/gem_softpin@safe-alignment
 - the gem_close_race fixture, used by all of its subtests whenever
   the kernel disallows relocations

Both are fixed here, each in its own patch, by additionally requiring
gem_uses_full_ppgtt(), consistent with the rest of gem_softpin.c and
with __intel_bb_create()'s own logic. All other call sites (used by
gem_ccs, gem_exercise_blt, api_intel_bb, intel_compute and the
allocator/batchbuffer libraries themselves) were checked and found to
already be correctly gated, directly or through hardware support that
implies full-ppgtt in practice.

Assisted-by: GitHub Copilot (Claude Sonnet 5)

Janusz Krzysztofik (2):
  tests/intel/gem_softpin: Skip safe-alignment without full-ppgtt
  tests/intel/gem_close_race: Skip offset probing without full-ppgtt

 tests/intel/gem_close_race.c | 19 ++++++++++++++-----
 tests/intel/gem_softpin.c    | 13 ++++++++++++-
 2 files changed, 26 insertions(+), 6 deletions(-)

-- 
2.55.0


^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2026-10-06 14:28 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-09-24 15:24 [PATCH i-g-t 0/2] tests/intel: Don't probe intel_allocator offsets without full-ppgtt Janusz Krzysztofik
2026-09-24 15:24 ` [PATCH i-g-t 1/2] tests/intel/gem_softpin: Skip safe-alignment " Janusz Krzysztofik
2026-09-25  7:54   ` Zbigniew Kempczyński
2026-09-25  9:30   ` Krzysztof Karas
2026-09-24 15:24 ` [PATCH i-g-t 2/2] tests/intel/gem_close_race: Skip offset probing " Janusz Krzysztofik
2026-09-25  8:40   ` Zbigniew Kempczyński
2026-09-25  9:47     ` Janusz Krzysztofik
2026-10-06 14:27       ` Kamil Konieczny
2026-09-25 10:41   ` Krzysztof Karas
2026-09-24 18:10 ` ✓ i915.CI.BAT: success for tests/intel: Don't probe intel_allocator offsets " Patchwork
2026-09-24 19:13 ` ✓ Xe.CI.BAT: " Patchwork
2026-09-25  8:08 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-09-25 21:21 ` ✗ i915.CI.Full: " Patchwork
2026-10-01 17:22 ` ✓ i915.CI.BAT: success for tests/intel: Don't probe intel_allocator offsets without full-ppgtt (rev2) Patchwork
2026-10-01 21:09 ` ✓ Xe.CI.BAT: " Patchwork
2026-10-02  1:49 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-10-02 23:08 ` ✗ i915.CI.Full: " Patchwork
2026-10-05  8:13   ` Janusz Krzysztofik
2026-10-05 11:32     ` Ravali, JupallyX
2026-10-05 11:27 ` ✓ i915.CI.Full: success " Patchwork

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox