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 <[email protected]> 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/[email protected]?part=4
