From: sashiko-bot@kernel.org
To: "Karl Mehltretter" <kmehltretter@gmail.com>
Cc: media-ci@linuxtv.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2] udmabuf: respect the device's maximum segment size
Date: Tue, 29 Sep 2026 06:00:27 +0000 [thread overview]
Message-ID: <20260929060028.371041F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260929054835.94118-1-kmehltretter@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] dma-buf: udmabuf CPU mapping fails on arches with PAGE_SIZE > 64KB
--
commit 8fabdc29555a534a611bda125124d9a796d8f300
Author: Karl Mehltretter <kmehltretter@gmail.com>
udmabuf: respect the device's maximum segment size
The commit fixes how get_sg_table() allocates scatterlists by passing the
device's maximum segment size to the scatterlist allocator. It returns
-EINVAL if the limit is smaller than PAGE_SIZE.
> diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
> index df6dd00462423..018937435356e 100644
> --- a/drivers/dma-buf/udmabuf.c
> +++ b/drivers/dma-buf/udmabuf.c
> @@ -133,15 +133,22 @@ static struct sg_table *get_sg_table(struct device *dev, struct dma_buf *buf,
> {
> struct udmabuf *ubuf = buf->priv;
> struct sg_table *sg;
> + unsigned int max_segment;
> int ret;
>
> + max_segment = dma_get_max_seg_size(dev);
> + /* The SG allocator requires a segment limit of at least PAGE_SIZE. */
> + if (max_segment < PAGE_SIZE)
> + return ERR_PTR(-EINVAL);
[Severity: High]
Does this unintentionally cause CPU mappings to unconditionally fail on
architectures with a PAGE_SIZE larger than 64KB?
When dma_buf_begin_cpu_access() is called for a udmabuf, it invokes
get_sg_table() using udmabuf_misc.this_device.
Because this misc device is initialized without setting up dma_parms or
max_segment_size:
drivers/dma-buf/udmabuf.c:udmabuf_dev_init() {
...
ret = dma_coerce_mask_and_coherent(udmabuf_misc.this_device,
DMA_BIT_MASK(64));
...
}
dma_get_max_seg_size() blindly returns the fallback default of SZ_64K.
On architectures with a 256KB PAGE_SIZE (such as Hexagon or PowerPC), this
new validation evaluates to 65536 < 262144, unconditionally returning
-EINVAL and breaking all CPU mappings.
> +
> sg = kzalloc_obj(*sg);
> if (!sg)
> return ERR_PTR(-ENOMEM);
>
> - ret = sg_alloc_table_from_pages(sg, ubuf->pages, ubuf->pagecount, 0,
> - ubuf->pagecount << PAGE_SHIFT,
> - GFP_KERNEL);
> + ret = sg_alloc_table_from_pages_segment(sg, ubuf->pages, ubuf->pagecount,
> + 0, ubuf->pagecount << PAGE_SHIFT,
> + max_segment,
> + GFP_KERNEL);
> if (ret < 0)
> goto err_alloc;
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260929054835.94118-1-kmehltretter@gmail.com?part=1
next prev parent reply other threads:[~2026-09-29 6:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-29 5:48 [PATCH v2] udmabuf: respect the device's maximum segment size Karl Mehltretter
2026-09-29 6:00 ` sashiko-bot [this message]
2026-09-29 6:56 ` Karl Mehltretter
2026-09-29 12:03 ` Jason Gunthorpe
2026-09-29 19:53 ` [PATCH v2] udmabuf: respect the device's maximum segment sizeg Karl Mehltretter
2026-09-29 12:10 ` [PATCH v2] udmabuf: respect the device's maximum segment size 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=20260929060028.371041F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=kmehltretter@gmail.com \
--cc=media-ci@linuxtv.org \
--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.