The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Lizhi Hou <lizhi.hou@amd.com>
To: "Christian König" <christian.koenig@amd.com>,
	"Taimuraz Kaitmazov" <taimuraz@kaitmazov.com>,
	"Min Ma" <mamin506@gmail.com>, "Oded Gabbay" <ogabbay@kernel.org>
Cc: Sumit Semwal <sumit.semwal@linaro.org>,
	Max Zhen <max.zhen@amd.com>,
	"Sonal Santan" <sonal.santan@amd.com>,
	<dri-devel@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>,
	<linux-media@vger.kernel.org>, <linaro-mm-sig@lists.linaro.org>
Subject: Re: [PATCH v3 1/3] accel/amdxdna: refuse an I/O memory mapping of an imported BO
Date: Mon, 24 Aug 2026 09:08:03 -0700	[thread overview]
Message-ID: <a782e2ad-d12a-66c8-447c-725d8e66593d@amd.com> (raw)
In-Reply-To: <87c9bb85-2514-44ac-a976-e24526c7f76e@amd.com>


On 8/24/26 07:06, Christian König wrote:
> On 8/17/26 19:53, Lizhi Hou wrote:
>> On 8/13/26 09:46, Taimuraz Kaitmazov wrote:
>>> amdxdna_gem_obj_vmap() takes whatever dma_buf_vmap() returns and only
>>> rejects a NULL vaddr. iosys_map is discriminated by is_iomem, so an
>>> exporter answering with an I/O mapping leaves a void __iomem pointer in
>>> abo->mem.kva, which amdxdna_cmd_set_error() memsets and memcpys through.
>>>
>>> amdxdna_drm_va_tbl takes a dmabuf_fd, so such a BO can be any exporter's
>>> buffer. amdgpu cannot reach this: its .pin forces GTT for a non peer to
>>> peer attachment like ours. An exporter on drm_gem_prime_dmabuf_ops has
>>> no .pin, and drm_gem_ttm_vmap() answers iomem for a VRAM resident
>>> object, so an NPU paired with nouveau or radeon does.
>>>
>>> Refuse the mapping. vmw_gem_vmap() does the same; unlike that one this
>>> path is reachable from an unprivileged ioctl, so it does not warn.
>>>
>>> Signed-off-by: Taimuraz Kaitmazov <taimuraz@kaitmazov.com>
>>> ---
>>>    drivers/accel/amdxdna/amdxdna_gem.c | 10 ++++++++--
>>>    1 file changed, 8 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/accel/amdxdna/amdxdna_gem.c b/drivers/accel/amdxdna/amdxdna_gem.c
>>> index 1f190b319bb..b66ec9e4828 100644
>>> --- a/drivers/accel/amdxdna/amdxdna_gem.c
>>> +++ b/drivers/accel/amdxdna/amdxdna_gem.c
>>> @@ -683,10 +683,16 @@ static int amdxdna_gem_obj_vmap(struct drm_gem_object *obj, struct iosys_map *ma
>>>          dma_resv_assert_held(obj->resv);
>>>    -    if (is_import_bo(abo))
>>> +    if (is_import_bo(abo)) {
>>>            ret = dma_buf_vmap(abo->dma_buf, map);
> Mhm, why does amdxdna a vmap in the first place? For some workaround?

This is used for flushing the imported BO before. Based on our 
discussion before, the driver should not flush imported BO, so this 
becomes a invalid case.

On the other hand, vmap on a io_mem should not happen. So I suggested to 
move the check to amdxdna_gem_vmap() for an extra check.


Thanks,

Lizhi

>
> Usually DMA-buf only provides that framebuffer emulation scanout inside the kernel.
>
> On the other hand as far as I can see that here should work correctly.
>
> Regards,
> Christian.
>
>>> -    else
>>> +        /* Callers use mem.kva as an ordinary kernel address. */
>>> +        if (!ret && map->is_iomem) {
>>> +            dma_buf_vunmap(abo->dma_buf, map);
>>> +            return -EOPNOTSUPP;
>>> +        }
>> Thanks for the fix. The 'is_iomem' check should be moved to amdxdna_gem_vmap() to cover all the cases.
>>
>> Lizhi
>>
>>> +    } else {
>>>            ret = drm_gem_shmem_object_vmap(obj, map);
>>> +    }
>>>        if (ret)
>>>            return ret;
>>>        if (!map->vaddr)

  reply	other threads:[~2026-08-24 16:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260813164700.43960-1-taimuraz@kaitmazov.com>
     [not found] ` <20260813164700.43960-2-taimuraz@kaitmazov.com>
2026-08-17 17:53   ` [PATCH v3 1/3] accel/amdxdna: refuse an I/O memory mapping of an imported BO Lizhi Hou
2026-08-24 14:06     ` Christian König
2026-08-24 16:08       ` Lizhi Hou [this message]
2026-08-26  8:37         ` Christian König

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=a782e2ad-d12a-66c8-447c-725d8e66593d@amd.com \
    --to=lizhi.hou@amd.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mamin506@gmail.com \
    --cc=max.zhen@amd.com \
    --cc=ogabbay@kernel.org \
    --cc=sonal.santan@amd.com \
    --cc=sumit.semwal@linaro.org \
    --cc=taimuraz@kaitmazov.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