Re: [PATCH 0/3] migration: switch remaining positioned I/O to _all helpers

[Peter Xu <peterx@redhat.com>]

On Sun, Apr 26, 2026 at 11:27:08AM +0300, Michael Tokarev wrote:
> On 20.04.2026 23:13, Junjie Cao wrote:
> > Follow-up to the pread/pwrite_all API series [1].
> > 
> > qemu_put_buffer_at(), qemu_get_buffer_at(), and file_write_ramblock_iov()
> > all use single-shot positioned I/O without retry.  They share the same
> > pattern as the bug fixed in multifd_file_recv_data() where a short
> > transfer would be mishandled.
> > 
> > Convert them to the _all helpers and clean up a pre-existing
> > const-correctness issue in qemu_get_buffer_at() along the way.
> > 
> > After this series no positioned I/O call site in migration/ uses raw
> > single-shot channel operations.
> > 
> > Depends-on: <20260413214549.926435-1-junjie.cao@intel.com>
> > ("io/channel: complete pread/pwrite_all API and fix
> > multifd_file_recv_data")
> > 
> > [1] https://lore.kernel.org/qemu-devel/20260413214549.926435-1-junjie.cao@intel.com/
> > 
> > Junjie Cao (3):
> >    migration/qemu-file: switch buffer_at functions to positioned I/O _all
> >      helpers
> >    migration/file: switch file_write_ramblock_iov to pwritev_all
> >    migration/qemu-file: drop incorrect const from qemu_get_buffer_at buf
> > 
> >   migration/file.c      |  8 ++++----
> >   migration/qemu-file.c | 37 ++++---------------------------------
> >   migration/qemu-file.h |  2 +-
> >   3 files changed, 9 insertions(+), 38 deletions(-)
> 
> And just like the previous changes in this area, - should I pick these 3
> to the current qemu-stable series, or is it not needed?
> 
> Applies to 10.0.x series and passes tests, but I haven't done any more
> testing here.

My understanding is we don't yet have a real report / reproducer for the
partial-io issue fixed here. Considering the size of the patchsets
(especially the dependency series), maybe we can skip these two sets of
patches until we know a solid report from anyone.

Junjie, did you find & fix this problem due to a real bug, or it was
theoretical while you were reading the code?

Thanks,

-- 
Peter Xu