Hit the same issue on qemu-guest-agent-2.12.0-3.el7



+++ This bug was initially created as a clone of Bug #1719548 +++

Description of problem:
Issue {"execute": "guest-file-read", "arguments": {"handle": 1000, "count": 10000000000}} qemu-guest-agent command from host, can't have response and the handle is closed.

Version-Release number of selected component (if applicable):
host(rhel8.1 slow train):
qemu-kvm-2.12.0-74.module+el8.1.0+3227+57d66ad3.x86_64
kernel-4.18.0-100.el8.x86_64
seabios-bin-1.11.1-3.module+el8.1.0+2983+b2ae9c0a.noarch

guest(rhel8.1 slow train):
qemu-guest-agent-2.12.0-74.module+el8.1.0+3227+57d66ad3.x86_64
kernel-4.18.0-103.el8.x86_64

How reproducible:
100%

Steps to Reproduce:
1.boot up guest with qemu-guest-agent needed command line.
-device virtio-serial-pci,id=virtio-serial1,max_ports=31,bus=pcie-root-port-4 \
-chardev socket,id=channel2,path=/tmp/helloworld2,server,nowait  -device virtserialport,bus=virtio-serial1.0,chardev=channel2,name=org.qemu.guest_agent.0 \

2.create a 200k file in guest.
# dd if=/dev/urandom of=/tmp/big_file bs=1024 count=200

3.open the big file with default mode(read only), and read it with a large count.
# nc -U /tmp/helloworld2 
{"execute": "guest-file-open", "arguments": {"path": "/tmp/big_file"}}
{"return": 1000}
{"execute": "guest-file-read", "arguments": {"handle": 1000, "count": 10000000000}}

===========wait 20s and no response.

3.read the file again.
{"execute": "guest-file-read", "arguments": {"handle": 1000, "count": 10000000000}}
{"error": {"class": "GenericError", "desc": "handle '1000' has not been found"}}

===========handle can't be found.

Actual results:
as step 2 and step 3

Expected results:
after step 3, can get response,such as error info.
And the handle can be found.


Additional info:
1. Install qemu-guest-agent-4.0.0-3.module+el8.1.0+3265+26c4ed71.x86_64.rpm in guest, can have response.
{"error": {"class": "GenericError", "desc": "value '10000000000' is invalid for argument count"}}
2. Install qemu-guest-agent-3.1.0-27.module+el8.0.1+3253+c5371cb3.x86_64.rpm, also can get the above response.
3. In rhel7.7 with qemu-guest-agent-2.12.0-3.el7,also hit this issue.

--- Additional comment from Marc-Andre Lureau on 2019-06-26 00:00:59 UTC ---

I am not able to reproduce, but I can imagine g_malloc() would abort in some cases.

We could backport:

commit 141b197408ab398c4f474ac1a728ab316e921f2b
Author: Prasad J Pandit <pjp@fedoraproject.org>
Date:   Wed Jun 13 11:46:57 2018 +0530

    qga: check bytes count read by guest-file-read

That helps.

Please check with this brew build: http://brewweb.devel.redhat.com/brew/taskinfo?taskID=22357644

--- Additional comment from  on 2019-06-26 03:22:45 UTC ---

(In reply to Marc-Andre Lureau from comment #1)
> I am not able to reproduce, but I can imagine g_malloc() would abort in some
> cases.
> 
> We could backport:
> 
> commit 141b197408ab398c4f474ac1a728ab316e921f2b
> Author: Prasad J Pandit <pjp@fedoraproject.org>
> Date:   Wed Jun 13 11:46:57 2018 +0530
> 
>     qga: check bytes count read by guest-file-read
> 
> That helps.
> 
> Please check with this brew build:
> http://brewweb.devel.redhat.com/brew/taskinfo?taskID=22357644

It works,can get a reasonable response with the brew build.

{"execute": "guest-file-open", "arguments": {"path": "/tmp/big_file"}}
{"return": 1000}
{"execute": "guest-file-read", "arguments": {"handle": 1000, "count": 10000000000}}
{"error": {"class": "GenericError", "desc": "value '10000000000' is invalid for argument count"}}
{"execute": "guest-file-read", "arguments": {"handle": 1000, "count": 10000000000}}

--- Additional comment from  on 2019-06-26 03:24:00 UTC ---

Btw, 
In rhel7.7 with qemu-guest-agent-2.12.0-3.el7,also hit this issue, so do I need clone one bug in RHEL7.7?

--- Additional comment from Marc-Andre Lureau on 2019-06-26 09:56:17 UTC ---

(In reply to xiagao from comment #3)
> Btw, 
> In rhel7.7 with qemu-guest-agent-2.12.0-3.el7,also hit this issue, so do I
> need clone one bug in RHEL7.7?

The impact is pretty low, and the abort() could still occur, even with that 4G limit. We could have an additional patch to use g_try_malloc() instead on those paths.

I guess we could backport to rhel7.7 in this case.