From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: drm/i915/display: Make fence timeout infinite Date: Sun, 12 Apr 2026 12:04:48 +1000 Message-ID: In-Reply-To: <20260408233458.22666-7-ville.syrjala@linux.intel.com> References: <20260408233458.22666-1-ville.syrjala@linux.intel.com> <20260408233458.22666-7-ville.syrjala@linux.intel.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Patch Review Switches from `i915_fence_timeout()` (10 seconds) to `MAX_SCHEDULE_TIMEOUT`= (infinite). The commit message itself expresses uncertainty: > "I'm not actually convinced we want an infinite timeout here because the = fence could be from an entirely different device/driver" This is a valid concern. With the reset fence mechanism from patch 5, the G= PU-hung case is handled, but fences from other drivers (e.g., in multi-GPU = or import scenarios) would cause an infinite hang with no recovery. The aut= hor notes this is for CI experimentation. **This patch should not be merged as-is** =E2=80=94 the commit message says= as much. For production, a generous-but-finite timeout (or the existing 10= s) would be safer, perhaps with the reset fence providing the fast-path esc= ape from GPU hangs. One note: if this does go in, the `ret <=3D 0` check after `dma_fence_wait_= any_timeout` with `MAX_SCHEDULE_TIMEOUT` means `ret =3D=3D 0` (timeout) can= never happen, so only `ret < 0` (signal interrupted, which can't happen wi= th `intr=3Dfalse`) would break. Effectively the loop becomes unbreakable ex= cept by fence completion =E2=80=94 which is the intent. --- Generated by Claude Code Patch Reviewer