All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Brzezinka <sebastian.brzezinka@intel.com>
To: Krzysztof Karas <krzysztof.karas@intel.com>,
	<intel-gfx@lists.freedesktop.org>
Cc: Andi Shyti <andi.shyti@linux.intel.com>,
	Sebastian Brzezinka <sebastian.brzezinka@intel.com>,
	Krzysztof Niemiec <krzysztof.niemiec@intel.com>,
	Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Subject: Re: [RFC 1/2] drm/i915/shmem: Prevent overflows on small segments
Date: Thu, 28 May 2026 15:55:53 +0200	[thread overview]
Message-ID: <DIUD102LPZ8R.166MO2E63L1MG@intel.com> (raw)
In-Reply-To: <20260527140804.2866189-2-krzysztof.karas@intel.com>

Hi Krzysztof,

On Wed May 27, 2026 at 4:08 PM CEST, Krzysztof Karas wrote:
> With addition of commit 029ae067431a
> ("drm/i915: Fix potential overflow of shmem scatterlist length")
> max_segment size was included in calculating a number of pages
> for the scatterlist. This meant that segment sizes considerably
> smaller than number of pages in a folio [1], were not enough to
> jump to the next folio. In result, sg_set_folio() was called
> multiple times with nr_pages smaller than folio size, using
> many scatterlists, all pointing to the beginning pages of the
> folio and never fully covering its range of pages and corrupting
> mappings.
>
> [1] See shmem_get_pages(), where segment size is set to
> PAGE_SIZE.
>
> Suggested-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> Fixes: 029ae067431a ("drm/i915: Fix potential overflow of shmem scatterlist length")
> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/15816
> Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com>
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> index 06543ae60706..ac9b263c341a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> @@ -156,7 +156,7 @@ int shmem_sg_alloc_table(struct drm_i915_private *i915, struct sg_table *st,
>  		nr_pages = min_array(((unsigned long[]) {
>  					folio_nr_pages(folio),
>  					page_count - i,
> -					max_segment / PAGE_SIZE,
> +					i915_sg_segment_size(i915->drm.dev) / PAGE_SIZE,
I don't think we can use i915_sg_segment_size() here, please correct me
if I'm wrong.

When DMA mapping fails, shmem_get_pages() sets max_segment = PAGE_SIZE
and retries. If we replace max_segment with i915_sg_segment_size() in the
min_array, nothing really changes between the first and second attempt,
we end up computing the same nr_pages as before and building the same
sg table that just failed to map.

It also breaks the sg->length check on line 163. After the first folio,
sg->length equals i915_sg_segment_size(). With max_segment=PAGE_SIZE the
check sg->length >= max_segment is always true, never and the PAGE_SIZE
retry has no effect.

-- 
Best regards,
Sebastian


  parent reply	other threads:[~2026-05-28 13:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-27 14:08 [RFC 0/2] Improve memory management for large object allocations when i915/shmem is used with iommu Krzysztof Karas
2026-05-27 14:08 ` [RFC 1/2] drm/i915/shmem: Prevent overflows on small segments Krzysztof Karas
2026-05-27 14:29   ` Janusz Krzysztofik
2026-05-28 13:55   ` Sebastian Brzezinka [this message]
2026-05-29 11:25     ` Janusz Krzysztofik
2026-06-01  6:13       ` Krzysztof Karas
2026-05-27 14:08 ` [RFC 2/2] drivers/iommu: Unroll unsuccessful mapping Krzysztof Karas
2026-05-27 14:36   ` Janusz Krzysztofik
2026-05-27 15:04 ` ✗ i915.CI.BAT: failure for Improve memory management for large object allocations when i915/shmem is used with iommu 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=DIUD102LPZ8R.166MO2E63L1MG@intel.com \
    --to=sebastian.brzezinka@intel.com \
    --cc=andi.shyti@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=janusz.krzysztofik@linux.intel.com \
    --cc=krzysztof.karas@intel.com \
    --cc=krzysztof.niemiec@intel.com \
    /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.