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

[Hanna Czenczek <hreitz@redhat.com>]

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:
> 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