Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Summers, Stuart" <stuart.summers@intel.com>
To: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
	"Auld,  Matthew" <matthew.auld@intel.com>
Cc: "Patelczyk, Maciej" <maciej.patelczyk@intel.com>,
	"Brost, Matthew" <matthew.brost@intel.com>
Subject: Re: [PATCH v2 1/3] drm/xe/migrate: prevent infinite recursion
Date: Thu, 31 Jul 2025 14:28:19 +0000	[thread overview]
Message-ID: <2d22bc3b1d8e98943d47914044f3f02d558faf9e.camel@intel.com> (raw)
In-Reply-To: <20250731093807.207572-6-matthew.auld@intel.com>

On Thu, 2025-07-31 at 10:38 +0100, Matthew Auld wrote:
> If the buf + offset is not aligned to XE_CAHELINE_BYTES we fallback
> to
> using a bounce buffer. However the bounce buffer here is allocated on
> the stack, and the only alignment requirement here is that it's
> naturally aligned to u8, and not XE_CACHELINE_BYTES. If the bounce
> buffer is also misaligned we then recurse back into the function
> again,
> however the new bounce buffer might also not be aligned, and might
> never
> be until we eventually blow through the stack, as we keep recursing.
> 
> Instead of using the stack use kmalloc, which should respect the
> power-of-two alignment request here. Fixes a kernel panic when
> triggering this path through eudebug.
> 
> v2 (Stuart):
>  - Add build bug check for power-of-two restriction
>  - s/EINVAL/ENOMEM/
> 
> Fixes: 270172f64b11 ("drm/xe: Update xe_ttm_access_memory to use GPU
> for non-visible access")
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Maciej Patelczyk <maciej.patelczyk@intel.com>
> Cc: Stuart Summers <stuart.summers@intel.com>
> Cc: Matthew Brost <matthew.brost@intel.com>
> ---
>  drivers/gpu/drm/xe/xe_migrate.c | 32 ++++++++++++++++++++-----------
> -
>  1 file changed, 20 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_migrate.c
> b/drivers/gpu/drm/xe/xe_migrate.c
> index 3a276e2348a2..b8d1ec4c1861 100644
> --- a/drivers/gpu/drm/xe/xe_migrate.c
> +++ b/drivers/gpu/drm/xe/xe_migrate.c
> @@ -1987,15 +1987,22 @@ int xe_migrate_access_memory(struct
> xe_migrate *m, struct xe_bo *bo,
>         if (!IS_ALIGNED(len, XE_CACHELINE_BYTES) ||
>             !IS_ALIGNED((unsigned long)buf + offset,
> XE_CACHELINE_BYTES)) {
>                 int buf_offset = 0;
> +               void *bounce;
> +               int err;
> +
> +               BUILD_BUG_ON(!is_power_of_2(XE_CACHELINE_BYTES));
> +               bounce = kmalloc(XE_CACHELINE_BYTES, GFP_KERNEL);
> +               if (!bounce)
> +                       return -ENOMEM;
> +
> +               xe_assert(xe, IS_ALIGNED((unsigned long)bounce,
> +                                        XE_CACHELINE_BYTES));

Personally I think this is a little overkill. I guess it does save us
in case that pow-of-2 requirement in kmalloc changes, but as discussed
in for instance https://lwn.net/Articles/802469/, a lot of other kernel
usages would fail if this was the case.

But also.. not a problem having it either, just the extra code.

Reviewed-by: Stuart Summers <stuart.summers@intel.com>

Thanks for the fix!

-Stuart

>  
>                 /*
>                  * Less than ideal for large unaligned access but
> this should be
>                  * fairly rare, can fixup if this becomes common.
>                  */
>                 do {
> -                       u8 bounce[XE_CACHELINE_BYTES];
> -                       void *ptr = (void *)bounce;
> -                       int err;
>                         int copy_bytes = min_t(int, bytes_left,
>                                                XE_CACHELINE_BYTES -
>                                                (offset &
> XE_CACHELINE_MASK));
> @@ -2004,22 +2011,22 @@ int xe_migrate_access_memory(struct
> xe_migrate *m, struct xe_bo *bo,
>                         err = xe_migrate_access_memory(m, bo,
>                                                        offset &
>                                                       
> ~XE_CACHELINE_MASK,
> -                                                      (void *)ptr,
> -                                                     
> sizeof(bounce), 0);
> +                                                      bounce,
> +                                                     
> XE_CACHELINE_BYTES, 0);
>                         if (err)
> -                               return err;
> +                               break;
>  
>                         if (write) {
> -                               memcpy(ptr + ptr_offset, buf +
> buf_offset, copy_bytes);
> +                               memcpy(bounce + ptr_offset, buf +
> buf_offset, copy_bytes);
>  
>                                 err = xe_migrate_access_memory(m, bo,
>                                                                offset
> & ~XE_CACHELINE_MASK,
> -                                                              (void
> *)ptr,
> -                                                             
> sizeof(bounce), write);
> +                                                             
> bounce,
> +                                                             
> XE_CACHELINE_BYTES, write);
>                                 if (err)
> -                                       return err;
> +                                       break;
>                         } else {
> -                               memcpy(buf + buf_offset, ptr +
> ptr_offset,
> +                               memcpy(buf + buf_offset, bounce +
> ptr_offset,
>                                        copy_bytes);
>                         }
>  
> @@ -2028,7 +2035,8 @@ int xe_migrate_access_memory(struct xe_migrate
> *m, struct xe_bo *bo,
>                         offset += copy_bytes;
>                 } while (bytes_left);
>  
> -               return 0;
> +               kfree(bounce);
> +               return err;
>         }
>  
>         dma_addr = xe_migrate_dma_map(xe, buf, len + page_offset,
> write);


  reply	other threads:[~2025-07-31 14:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-31  9:38 [PATCH v2 0/3] Some more xe_migrate_access_memory fixes Matthew Auld
2025-07-31  9:38 ` [PATCH v2 1/3] drm/xe/migrate: prevent infinite recursion Matthew Auld
2025-07-31 14:28   ` Summers, Stuart [this message]
2025-07-31  9:38 ` [PATCH v2 2/3] drm/xe/migrate: don't overflow max copy size Matthew Auld
2025-07-31  9:38 ` [PATCH v2 3/3] drm/xe/migrate: prevent potential UAF Matthew Auld
2025-07-31 10:50 ` ✗ CI.checkpatch: warning for Some more xe_migrate_access_memory fixes (rev2) Patchwork
2025-07-31 10:51 ` ✓ CI.KUnit: success " Patchwork
2025-07-31 11:53 ` ✓ Xe.CI.BAT: " Patchwork
2025-07-31 13:01 ` ✗ Xe.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=2d22bc3b1d8e98943d47914044f3f02d558faf9e.camel@intel.com \
    --to=stuart.summers@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=maciej.patelczyk@intel.com \
    --cc=matthew.auld@intel.com \
    --cc=matthew.brost@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox