1984721 – Unclear error message while hotplugging the same chardev

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1984721 - Unclear error message while hotplugging the same chardev

Summary: Unclear error message while hotplugging the same chardev

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 8
Classification:	Red Hat
Component:	qemu-kvm
Sub Component:
Version:	8.5
Hardware:	x86_64
OS:	Linux
Priority:	medium
Severity:	medium
Target Milestone:	rc
Target Release:	8.6
Assignee:	Marc-Andre Lureau
QA Contact:	liunana
Docs Contact:
URL:
Whiteboard:
Depends On:	1997410
Blocks:	2001316
TreeView+	depends on / blocked

Reported:	2021-07-22 02:14 UTC by liunana
Modified:	2022-05-10 13:29 UTC (History)
CC List:	8 users (show)
Fixed In Version:	qemu-kvm-6.1.0-2.module+el8.6.0+12861+13975d62
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Clones:	2001316 (view as bug list)
Environment:
Last Closed:	2022-05-10 13:20:14 UTC
Type:	---
Target Upstream Version:
Embargoed:
Dependent Products:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHSA-2022:1759	0	None	None	None	2022-05-10 13:21:17 UTC

Description liunana 2021-07-22 02:14:01 UTC

Description of problem:
unclear error message while hotplugging the same chardev


Version-Release number of selected component (if applicable):
Host:    
    kernel-4.18.0-323.el8.x86_64 
    qemu-kvm-6.0.0-24.module+el8.5.0+11844+1e3017bd.x86_64
    



How reproducible: 100%


Steps to Reproduce:
1. Boot qemu with cmdline:
   /usr/libexec/qemu-kvm -monitor stdio -qmp tcp:0:4445,server=on,wait=off

2. Hotplug chardev:
  {"execute":"chardev-add","arguments":{"id":"char2","backend":{"type":"socket","data":{"addr":{"type":"unix", "data": {"path": "/home/mm"}}}}}}
  {"return": {}}

3. Hotplug the same chardev again:
  {"execute":"chardev-add","arguments":{"id":"char2","backend":{"type":"socket","data":{"addr":{"type":"unix", "data": {"path": "/home/mm"}}}}}}
  {"error": {"class": "GenericError", "desc": "duplicate yank instance"}}

Actual results:
Can't tell what's the reason that cause the failure of hotplugging.


Expected results:
We should have reported
that the "id" value for the two chardevs is clashing.


Additional info:

Comment 1 liunana 2021-07-22 02:43:42 UTC

Slow train has no such issue:
    qemu-kvm-4.2.0-53.module+el8.5.0+11673+72138537.x86_64


{"execute":"chardev-add","arguments":{"id":"char2","backend":{"type":"socket","data":{"addr":{"type":"unix", "data": {"path": "/home/mm"}}}}}}
{"return": {}}
{"execute":"chardev-add","arguments":{"id":"char2","backend":{"type":"socket","data":{"addr":{"type":"unix", "data": {"path": "/home/mm"}}}}}}
{"error": {"class": "GenericError", "desc": "attempt to add duplicate property 'char2' to object (type 'container')"}}

Comment 2 Marc-Andre Lureau 2021-07-28 11:34:05 UTC

Would this be good enough?

{"error": {"class": "GenericError", "desc": "Failed to open chardev 'char2': duplicate yank instance"}}


> {"error": {"class": "GenericError", "desc": "attempt to add duplicate property 'char2' to object (type 'container')"}}

wasn't very friendly either..

Comment 3 liunana 2021-07-30 09:39:31 UTC

(In reply to Marc-Andre Lureau from comment #2)
> Would this be good enough?
> 
> {"error": {"class": "GenericError", "desc": "Failed to open chardev 'char2':
> duplicate yank instance"}}
> 

Hi,

It's good to contain the duplicate chardev id, thanks.
But seems 'open chardev' is not a match error log for duplicate hotplugging the same chardev.

How about:

{"error": {"class": "GenericError", "desc": "Failed to add chardev 'char2': duplicate yank instance"}}



Besides, would you please help to explain more about what's the 'yank' function in the error log? Thanks.


> 
> > {"error": {"class": "GenericError", "desc": "attempt to add duplicate property 'char2' to object (type 'container')"}}
> 
> wasn't very friendly either.


Seems clearer than "duplicate yank instance".




Best regards
Liu Nana

Comment 4 John Ferlan 2021-08-09 13:25:32 UTC

Moving this to 8.6, in POST, and setting DTM=5 since this can be tested/validated using the weekly rebase as the fix has gone into qemu-6.1.

Decision was to not backport for AV 8.5 since it's really an error path for newer code (yank functionality) that isn't necessarily reachable via libvirt or other means at this point. Neither RHV nor OSP will use 8.5.

Comment 5 John Ferlan 2021-09-05 13:55:02 UTC

Move to RHEL since RHEL-AV will only be a rebuild of RHEL starting w/ 8.6.0

Added the RHEL rebase bz to depends on list

Comment 8 Yanan Fu 2021-10-13 03:07:41 UTC

Set 'Verified:Tested,SanityOnly' as gating test with qemu-kvm-6.1.0-2.module+el8.6.0+12861+13975d62 pass.

Comment 9 liunana 2021-10-13 14:31:44 UTC

Verified this bug with qemu-kvm-6.1.0-2.module+el8.6.0+12861+13975d62.

1. Boot qemu with cmdline:
   /usr/libexec/qemu-kvm -monitor stdio -qmp tcp:0:4445,server=on,wait=off

2. Hotplug the same chardev, we can get the clear error log.
{"execute":"chardev-add","arguments":{"id":"char2","backend":{"type":"socket","data":{"addr":{"type":"unix", "data": {"path": "/home/mm"}}}}}}
{"return": {}}
{"execute":"chardev-add","arguments":{"id":"char2","backend":{"type":"socket","data":{"addr":{"type":"unix", "data": {"path": "/home/mm"}}}}}}
{"error": {"class": "GenericError", "desc": "Chardev with id 'char2' already exists"}}


Test Env:
    4.18.0-345.1.el8.x86_64
    qemu-kvm-6.1.0-2.module+el8.6.0+12861+13975d62.x86_64
    

I will move this bug to verified now, thanks.



Besides, seems two chardev backends can use the same path, is that normal?

# /usr/libexec/qemu-kvm -monitor stdio -qmp tcp:0:4445,server=on,wait=off -chardev socket,id=t1,path=/tmp/mm,server=on,wait=off -chardev socket,id=t2,path=/tmp/mm,server=on,wait=off
QEMU 6.1.0 monitor - type 'help' for more information
(qemu) VNC server running on ::1:5900
info chardev
t2: filename=disconnected:unix:/tmp/mm,server=on
t1: filename=disconnected:unix:/tmp/mm,server=on
compat_monitor1: filename=disconnected:tcp:0.0.0.0:4445,server=on


Would you please help to check this? Thanks!


Best regards
Liu Nana

Comment 10 Marc-Andre Lureau 2021-10-18 08:32:59 UTC

(In reply to liunana from comment #9)
> I will move this bug to verified now, thanks.
> 

thanks

> Besides, seems two chardev backends can use the same path, is that normal?
> 
> # /usr/libexec/qemu-kvm -monitor stdio -qmp tcp:0:4445,server=on,wait=off
> -chardev socket,id=t1,path=/tmp/mm,server=on,wait=off -chardev
> socket,id=t2,path=/tmp/mm,server=on,wait=off
> QEMU 6.1.0 monitor - type 'help' for more information
> (qemu) VNC server running on ::1:5900
> info chardev
> t2: filename=disconnected:unix:/tmp/mm,server=on
> t1: filename=disconnected:unix:/tmp/mm,server=on
> compat_monitor1: filename=disconnected:tcp:0.0.0.0:4445,server=on
> 
> 
> Would you please help to check this? Thanks!
> 

This expected, qemu has always unlink() the previous path before serving on unix socket.

(in general, UNIX paths aren't very robust, management applications should use different sockets)

Comment 12 errata-xmlrpc 2022-05-10 13:20:14 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: virt:rhel and virt-devel:rhel security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:1759

Note You need to log in before you can comment on or make changes to this bug.