Re: [PATCH v5 0/4] io_uring: extend bvec registration

[Jens Axboe <axboe@kernel.dk>]

On 4/3/26 11:30 AM, Joanne Koong wrote:
> On Fri, Apr 3, 2026 at 9:21 AM Jens Axboe <axboe@kernel.dk> wrote:
>>
>> On 4/2/26 10:09 AM, Joanne Koong wrote:
>>> This series refactors and extends the io_uring registered buffers
>>> infrastructure to allow external subsystems to register pre-existing bvec
>>> arrays directly.
>>>
>>> The motivation for the patches in this series is to make fuse zero-copy
>>> possible. These patches are split out from a previous larger
>>> fuse-over-io_uring series [1]. The fuse zero-copy work that builds on top of
>>> this is in [2].
>>>
>>> Thanks,
>>> Joanne
>>>
>>> [1] https://lore.kernel.org/linux-fsdevel/20260116233044.1532965-1-joannelkoong@gmail.com/
>>> [2] https://lore.kernel.org/linux-fsdevel/20260324224532.3733468-9-joannelkoong@gmail.com/
>>>
>>> Changelog:
>>> v4: https://lore.kernel.org/io-uring/20260327172631.3380702-1-joannelkoong@gmail.com/
>>> v4 -> v5:
>>> * rebase to origin/for-7.1/io_uring
>>> * drop the io_uring_registered_mem_region_get() patch
>>
>> Series looks good to me, but I don't think you used the right base? It
>> does not seem to apply to for-7.1/io_uring, patch 1 runs into issues on
>> the ublk part.
>>
>> Since this touches both and applies to neither right now, maybe do a
>> respin and just base it on my for-next. Then I'll setup a
>> for-7.1/io_uring-fuse branch that is just for-7.1/io_uring and
>> for-7.1/block merged together.
> 
> Ahh that's weird, it applies cleanly to for-7.1/io_uring on my end (on
> top of commit f847bf6d2930) but I do see some merge conflicts with
> for-next for the ublk commit 24d4c90286b9.

Right, sorry I wasn't clear, does apply to for-7.1/io_uring, but you
end up with non-trivial merge conflicts. It's always a bit tricky as
the ublk changes generally take the block route, not the io_uring
route, as it's more closely tied to that side.

> I'll rebase this to for-next and send that out.

Thanks!

-- 
Jens Axboe