qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Hanna Czenczek
Subject: Re: [RFC 0/2] Split padded I/O vectors exceeding IOV_MAX
Date: Wed, 15 Mar 2023 17:05:25 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]