From: sashiko-bot@kernel.org
To: "Pavel Begunkov" <asml.silence@gmail.com>
Cc: media-ci@linuxtv.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v9 04/13] block: introduce dma map backed bio type
Date: Wed, 07 Oct 2026 01:59:00 +0000 [thread overview]
Message-ID: <sashiko-outbox-162576@kernel.org> (raw)
In-Reply-To: <17dc7954fc8632ca4fb80cd4c892fc0c5ce2d11b.1791336930.git.asml.silence@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] block: type confusion in blk_recalc_rq_segments() for REQ_DMABUF bios
--
commit e3ead2f3d194e7e61660e2723f7786a4b6fec3ba
Author: Pavel Begunkov <asml.silence@gmail.com>
block: introduce dma map backed bio type
This patch introduces a dma map backed bio type. It repurposes the bi_io_vec
space in the bio structure to store dmabuf maps, as premapped buffers do not
require a generic bio_vec array.
> diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
> index 98e21b4cbf328..0cc09b975d8ff 100644
> --- a/include/linux/blk_types.h
> +++ b/include/linux/blk_types.h
> @@ -233,7 +233,12 @@ struct bio {
> atomic_t __bi_remaining;
>
> /* The actual vec list, preserved by bio_reset() */
> - struct bio_vec *bi_io_vec;
> + union {
> + struct bio_vec *bi_io_vec;
> + /* Driver specific dma map, valid IFF REQ_DMABUF is set */
> + struct dma_buf_io_map *bi_dmabuf_map;
> + };
> +
[Severity: High]
Does this memory alias cause a type confusion in existing block layer
functions that don't check for REQ_DMABUF?
For example, if a REQ_DMABUF request completes partially,
blk_update_request() will call blk_recalc_rq_segments(). That function
iterates over the request using rq_for_each_bvec(), which internally uses
bio_for_each_segment() and blindly dereferences bi_io_vec as a bio_vec
array because bio_has_data() evaluates to true for these bios.
This means it reads the memory of struct dma_buf_io_map as bv_page, bv_len,
and bv_offset. When the garbage bv_len is passed to
bio_advance_iter_single(), it subtracts it from iter->bi_size, which can
lead to an infinite loop or wild memory accesses when attempting to process
the segments.
Is there a need to update blk_recalc_rq_segments() or other iterators to
explicitly exclude REQ_DMABUF bios?
> struct bvec_iter bi_iter;
>
> union {
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1791336930.git.asml.silence@gmail.com?part=4
next prev parent reply other threads:[~2026-10-07 1:59 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-07 1:42 [PATCH v9 00/13] Add dmabuf read/write via io_uring Pavel Begunkov
2026-10-07 1:42 ` [PATCH v9 01/13] dma-buf: introduce initial file I/O infrastructure Pavel Begunkov
2026-10-07 1:52 ` sashiko-bot
2026-10-07 1:42 ` [PATCH v9 02/13] iov_iter: add iterator type for dmabuf maps Pavel Begunkov
2026-10-07 1:57 ` sashiko-bot
2026-10-07 1:42 ` [PATCH v9 03/13] block: always adjust bi_offset on bio_advance_iter Pavel Begunkov
2026-10-07 1:42 ` [PATCH v9 04/13] block: introduce dma map backed bio type Pavel Begunkov
2026-10-07 1:59 ` sashiko-bot [this message]
2026-10-07 1:42 ` [PATCH v9 05/13] block: add dma-buf support for raw bdev Pavel Begunkov
2026-10-08 12:27 ` Anuj Gupta/Anuj Gupta
2026-10-07 1:42 ` [PATCH v9 06/13] nvme-pci: rename nvme_pci_sgl_set_data to nvme_pci_dma_iter_set_sgl Pavel Begunkov
2026-10-07 1:42 ` [PATCH v9 07/13] nvme-pci: implement dma-buf backed requests Pavel Begunkov
2026-10-07 2:01 ` sashiko-bot
2026-10-07 1:42 ` [PATCH v9 08/13] nvme-pci: add SGL support for the dmabuf path Pavel Begunkov
2026-10-07 2:00 ` sashiko-bot
2026-10-07 1:42 ` [PATCH v9 09/13] io_uring/rsrc: introduce buf registration structure Pavel Begunkov
2026-10-07 1:42 ` [PATCH v9 10/13] io_uring/rsrc: extend buffer update Pavel Begunkov
2026-10-07 1:51 ` sashiko-bot
2026-10-07 1:42 ` [PATCH v9 11/13] io_uring/rsrc: add uncloneable regbuf flag Pavel Begunkov
2026-10-07 1:42 ` [PATCH v9 12/13] io_uring/rsrc: add regbuf import flags Pavel Begunkov
2026-10-07 1:42 ` [PATCH v9 13/13] io_uring/rsrc: add dmabuf backed registered buffers Pavel Begunkov
2026-10-07 1:55 ` sashiko-bot
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=sashiko-outbox-162576@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=asml.silence@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox