Re: [PATCH v2 04/14] drm/i915/gt: Open-code active timeline walk
Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/[email protected]> Tue, 9 Jun 2026 10:00:03 +0300
| Newsgroups | gmane.linux.kernel.spi.devel,gmane.linux.kernel.drbd.devel,gmane.linux.block,gmane.linux.kernel.firewire.devel,gmane.comp.video.dri.devel,gmane.comp.freedesktop.xorg.drivers.intel,gmane.linux.ports.arm.kernel,gmane.linux.ports.tegra,gmane.linux.sound,gmane.linux.kernel |
|---|---|
| Organization | Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo |
| Message-ID | <[email protected]> |
On Tue, Jun 09, 2026 at 02:25:16PM +0800, Kaitao Cheng wrote:
>
> A later change will make list_for_each_entry() cache the next element
> before entering the loop body. __intel_gt_unset_wedged() drops
> timelines->lock while waiting on a fence and then restarts the walk from
> the list head after the lock is reacquired.
>
> Keep the loop open-coded so the next timeline is selected after that
> restart logic has run. This preserves the existing lock-drop traversal
> semantics and prepares the code for the list iterator update.
...
> spin_lock(&timelines->lock);
> - list_for_each_entry(tl, &timelines->active_list, link) {
> + for (tl = list_first_entry(&timelines->active_list, typeof(*tl), link);
> + !list_entry_is_head(tl, &timelines->active_list, link);
> + tl = list_next_entry(tl, link)) {
Yeah, these cases should rather be converted to do {} while or while-loop.
This will make the intention clearer and reduces the possibility that someone
mistakenly changes these back to use list_for_each_entry().
See, for example, deferred_probe_work_func() implementation.
--
With Best Regards,
Andy Shevchenko