Re: [RFC 0/2] Split padded I/O vectors exceeding IOV_MAX

[Hanna Czenczek]

On 15.03.23 16:29, Stefan Hajnoczi wrote:
> On Wed, Mar 15, 2023 at 01:13:28PM +0100, Hanna Czenczek wrote:
> > Hi,
> >
> > We accept I/O vectors with up to 1024 (IOV_MAX) elements from guests.
> > When a guest request does not conform to the underlying storage's
> > alignment requirements, we pad it with head and/or tail buffers as
> > necessary, which are simply appended to the I/O vector.
> >
> > As of 4c002cef, we (sensibly) check that such-padded vectors do not then
> > exceed IOV_MAX.  However, there seems to be no sensible error handling;
> > instead, the guest simply receives an I/O error.
> >
> > That???s a problem, because it submitted a perfectly sensible I/O request
> Looks like there is an encoding issue. I get 3 question marks instead of
> an apostrophe. lore.kernel.org also renders mojibake:
> 20230315121330.29679-1-hreitz@redhat.com/">https://lore.kernel.org/qemu-devel/20230315121330.29679-1-hreitz@redhat.com/

Hm, yeah, no “charset=UTF-8” in that mail’s Content-type...  I think 
that’s because it just uses what’s in the patch file and sends it, and I 
needed to force it to be format.headers="Content-type: text/plain" in 
.gitconfig at some point because of some Mimecast thing.  I hope putting 
format.headers="Content-type: text/plain; charset=UTF-8" will fix that 
for the future.  Thanks for telling me!

Hanna