All of lore.kernel.org
 help / color / mirror / Atom feed
From: "José Expósito" <jose.exposito89@gmail.com>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	maarten.lankhorst@linux.intel.com, mripard@kernel.org,
	airlied@gmail.com, simona@ffwll.ch,
	boris.brezillon@collabora.com, kees@kernel.org
Subject: Re: [PATCH 0/2] drm/tests: shmem: Fix intermittent DMA overflow on ppc64le/s390x
Date: Fri, 3 Jul 2026 16:30:12 +0200	[thread overview]
Message-ID: <akfHdPXvbROST6eB@fedora> (raw)
In-Reply-To: <285af006-f403-4c3d-8cd6-e0318c188b85@suse.de>

On Fri, Jul 03, 2026 at 12:32:18PM +0200, Thomas Zimmermann wrote:
> Hi José
> Am 03.07.26 um 11:00 schrieb José Expósito:
> > Hi Thomas,
> > 
> > Thanks for your review.
> > 
> > On Fri, Jul 03, 2026 at 08:53:30AM +0200, Thomas Zimmermann wrote:
> > > Hi
> > > 
> > > Am 03.07.26 um 08:34 schrieb José Expósito:
> > > > Two drm_gem_shmem KUnit tests, drm_gem_shmem_test_get_pages_sgt() and
> > > > drm_gem_shmem_test_purge(), intermittently fail on ppc64le and s390x CI
> > > > with a DMA address overflow warning followed by -EIO:
> > > > 
> > > >     DMA addr 0x00000001130b0000+65536 overflow (mask ffffffff, bus limit 0).
> > > >     Expected sgt is not error, but is: -5
> > > > 
> > > > Both tests call `drm_gem_shmem_get_pages_sgt()`, which internally pins
> > > > backing pages and DMA-maps them via `dma_map_sgtable()`. The DMA mapping
> > > > path is:
> > > > 
> > > >     drm_gem_shmem_test_purge()
> > > >       drm_gem_shmem_get_pages_sgt()
> > > >         drm_gem_shmem_get_pages_sgt_locked() [drm_gem_shmem_helper.c]
> > > >           dma_map_sgtable()                  [mapping.c]
> > > >             __dma_map_sg_attrs()
> > > >               dma_direct_map_sg()            [direct.c]
> > > >                 dma_direct_map_phys()        [kernel/dma/direct.h]
> > > >                   dma_capable()              Checks addr against DMA mask
> > > >                     -> FAILS: addr > 0xFFFFFFFF
> > > > 
> > > > KUnit devices are initialized with a 32-bit DMA mask
> > > > (`DMA_BIT_MASK(32)`) in `lib/kunit/device.c`. On systems where the kernel
> > > > allocates backing pages at physical addresses above 4GB, `dma_capable()`
> > > > returns false because the address exceeds the 32-bit mask. The `dma_set_mask()`
> > > > function updates `*dev->dma_mask` to the given value; setting it to
> > > > `DMA_BIT_MASK(64)` allows any physical address to pass the check.
> > > > 
> > > > The failure is intermittent because pages may or may not be allocated
> > > > above 4GB on any given run depend on memory pressure.
> > > > 
> > > > A third test in the same suite, `drm_gem_shmem_test_obj_create_private`,
> > > > already calls `dma_set_mask(drm_dev->dev, DMA_BIT_MASK(64))` before its
> > > > DMA mapping. This series applies the same fix to the two remaining tests.
> > > Instead of doing whack-a-mole, is it possible to move the existing fix from
> > > drm_gem_shmem_test_obj_create_private() to _test_init at [1] ? The DMA mask
> > > would then be the same on all tests. [1] https://elixir.bootlin.com/linux/v7.1.2/source/drivers/gpu/drm/tests/drm_gem_shmem_test.c#L359
> > Yes, I think it is possible. However, this is an intermittent failure that
> > I couldn't reproduce locally and I tried to reduce as much as possible the
> > risk of regression limitting the change to the 2 affected tests.
> > 
> > I'm afraid I don't have enough knoledge about GEM's internals to know if moving
> > the fix to the init function could introduce unwanted side-effects in the other
> > tests. If you think it'd be safe, I'll trust you and move it.
> 
> Please do. I don't see why it should not work, and it's an easy revert it
> doesn't.

I just sent v2 with the suggested change. I run the test in several
architectures and I didn't run into any issue:

https://lore.kernel.org/dri-devel/20260703142749.4099-1-jose.exposito89@gmail.com/

Thanks,
Jose

> 
> Best regards
> Thomas
> 
> > 
> > Jose
> > 
> > PS - Next week I'll be away from keyboard, so any change would need to wait a bit
> > 
> > > Best regards Thomas
> > > > José Expósito (2):
> > > >     drm/tests: shmem: Set DMA mask to 64-bit in
> > > >       drm_gem_shmem_test_get_pages_sgt
> > > >     drm/tests: shmem: Set DMA mask to 64-bit in drm_gem_shmem_test_purge
> > > > 
> > > >    drivers/gpu/drm/tests/drm_gem_shmem_test.c | 9 ++++++++-
> > > >    1 file changed, 8 insertions(+), 1 deletion(-)
> > > > 
> > > -- 
> > > --
> > > Thomas Zimmermann
> > > Graphics Driver Developer
> > > SUSE Software Solutions Germany GmbH
> > > Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
> > > GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
> > > 
> > > 
> 
> -- 
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
> GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
> 
> 

      reply	other threads:[~2026-07-03 14:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-03  6:34 [PATCH 0/2] drm/tests: shmem: Fix intermittent DMA overflow on ppc64le/s390x José Expósito
2026-07-03  6:34 ` [PATCH 1/2] drm/tests: shmem: Set DMA mask to 64-bit in drm_gem_shmem_test_get_pages_sgt José Expósito
2026-07-03  6:34 ` [PATCH 2/2] drm/tests: shmem: Set DMA mask to 64-bit in drm_gem_shmem_test_purge José Expósito
2026-07-03  6:53 ` [PATCH 0/2] drm/tests: shmem: Fix intermittent DMA overflow on ppc64le/s390x Thomas Zimmermann
2026-07-03  9:00   ` José Expósito
2026-07-03 10:32     ` Thomas Zimmermann
2026-07-03 14:30       ` José Expósito [this message]

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=akfHdPXvbROST6eB@fedora \
    --to=jose.exposito89@gmail.com \
    --cc=airlied@gmail.com \
    --cc=boris.brezillon@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kees@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=tzimmermann@suse.de \
    /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.