All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Krzysztof Karas" <krzysztof.karas@intel.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 2/3] drm/i915/gem: split shared memory allocation table logic
Date: Thu, 25 Jun 2026 13:54:25 +0000	[thread overview]
Message-ID: <20260625135426.486191F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260625134342.1102921-3-krzysztof.karas@intel.com>

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 <krzysztof.karas@intel.com>

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/20260625134342.1102921-1-krzysztof.karas@intel.com?part=2

  reply	other threads:[~2026-06-25 13:54 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-25 13:43 [PATCH 0/3] drivers: Improve memory management for large object allocations when i915/shmem is used with iommu Krzysztof Karas
2026-06-25 13:43 ` [PATCH 1/3] drivers/iommu: Unroll unsuccessful mapping Krzysztof Karas
2026-06-25 13:57   ` sashiko-bot
2026-06-25 14:29   ` Robin Murphy
2026-06-25 15:48   ` Michał Grzelak
2026-06-25 13:43 ` [PATCH 2/3] drm/i915/gem: split shared memory allocation table logic Krzysztof Karas
2026-06-25 13:54   ` sashiko-bot [this message]
2026-06-25 13:43 ` [PATCH 3/3] drm/i915/shmem: Count mapped pages in a folio Krzysztof Karas
2026-06-25 16:43 ` ✓ i915.CI.BAT: success for drivers: Improve memory management for large object allocations when i915/shmem is used with iommu Patchwork
2026-06-25 23:16 ` ✗ i915.CI.Full: failure " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260625135426.486191F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=krzysztof.karas@intel.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.