Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Low] Unreachable WARN_ON_ONCE and error return in `shmem_shrink_get_folio`. --
commit fe135bc87bdc96f8bc699495fde11dd752239633 Author: Krzysztof Karas <[email protected]> drm/i915/gem: split shared memory allocation table logic This commit factors out the scatterlist allocation logic in shmem_sg_alloc_table into smaller helper functions. It introduces shmem_shrink_get_folio and validate_size, while changing the main loop structure to improve readability. > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c > b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c > index 06543ae60706e..b5ae7e5f80a06 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c [ ... ] > +static struct folio *shmem_shrink_get_folio(struct address_space *mapping, > + unsigned long folio_index, > + gfp_t gfp, unsigned int pages_left, > + struct drm_i915_private *i915) > +{ > +#define MAX_READS 2 > + struct folio *folio; > + unsigned int i; > + > + for (i = 0; i < MAX_READS; i++) { > + cond_resched(); > + folio = shmem_read_folio_gfp(mapping, folio_index, gfp); > + if (!IS_ERR(folio) || i == MAX_READS - 1) > + return folio; [ ... ] > + gfp |= __GFP_RETRY_MAYFAIL | __GFP_NOWARN; > + } > + > + /* Should never happen */ > + WARN_ON_ONCE(1); > + return ERR_PTR(-EINVAL); > +} [Severity: Low] Is this code unreachable? Looking at the loop termination logic above, the for loop will either exit early when !IS_ERR(folio) is true, or it will return directly on the final iteration when i == MAX_READS - 1. Because it always returns from within the loop body, it never falls through to the end of the function. Does this WARN_ON_ONCE and error return serve an intended purpose, or can it be safely removed as dead code? -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2
