Bug 2097209
| Summary: | [virtiofs] mount virtiofs failed: SELinux: (dev virtiofs, type virtiofs) getxattr errno 111 | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | xiagao |
| Component: | qemu-kvm | Assignee: | Dr. David Alan Gilbert <dgilbert> |
| qemu-kvm sub component: | virtio-fs | QA Contact: | xiagao |
| Status: | CLOSED ERRATA | Docs Contact: | |
| Severity: | high | ||
| Priority: | high | CC: | ailan, bugproxy, coli, dgilbert, jen, jinzhao, jmaloy, juzhang, kkiwi, kwolf, lijin, mdeng, menli, mrezanin, qizhu, smitterl, tstaudt, vgoyal, virt-maint, yfu, ymankad |
| Version: | 8.7 | Keywords: | Regression, TestBlocker, Triaged |
| Target Milestone: | rc | Flags: | pm-rhel:
mirror+
|
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | qemu-kvm-6.2.0-16.module+el8.7.0+15743+c774064d | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-11-08 09:20:10 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 2089955 | ||
This is a scenario in qemu-kvm component gating test can block the gating pass, so add TestBlocker, thanks! Pass on last version: qemu-kvm-core-6.2.0-14.module+el8.7.0+15289+26b4351e.x86_64 So, IIUC, qemu-kvm-core-6.2.0-14.module+el8.7.0+15289+26b4351e.x86_64 works but qemu-kvm-6.2.0-15.module+el8.7.0+15644+189a21f6.x86_64 fails? Right? While guest kernel remains the same on host and guest (kernel-4.18.0-400.el8.x86_64(host/guest)). Please confirm. If that's true, it points to some change going in qemu. That's a weird error; if It is between -14 and -15 I don't see any obvious cause: http://pkgs.devel.redhat.com/cgit/rpms/qemu-kvm/commit/?h=stream-rhel-rhel-8.7.0&id=907a8f8fa54eba8f7e86e74c62da6542a2e42ad5 I can confirm this on my test box. [(null)] [ID: 00000004] fv_queue_thread: Queue 1 gave evalue: 1 available: in: 80 out: 56 [(null)] [ID: 00000004] fv_queue_worker: elem 0: with 2 out desc of length 56 [(null)] [ID: 00000004] unique: 2, opcode: INIT (26), nodeid: 0, insize: 56, pid: 0 [(null)] [ID: 00000004] unique: 2, error: -22 (Invalid argument), outsize: 16 [(null)] [ID: 00000004] virtio_send_msg: elem 0: with 2 in desc of length 80 [(null)] [ID: 00000004] fv_queue_thread: Waiting for Queue 1 event [(null)] [ID: 00000001] virtio_loop: Got VU event I wonder if this is the kernel headers update that broke it. I think the problem here is the kernel header update and we probably need to pull in qemu's:
commit 776dc4b1650062099df3cb4f90fa01c8e73eecfa
Author: Vivek Goyal <vgoyal>
Date: Tue Feb 8 15:48:06 2022 -0500
virtiofsd: Parse extended "struct fuse_init_in"
Add some code to parse extended "struct fuse_init_in". And use a local
variable "flag" to represent 64 bit flags. This will make it easier
to add more features without having to worry about two 32bit flags (->flags
and ->flags2) in "fuse_struct_in".
commit a086d54c6ffa38f7e71f182b63a25315304a3392
Author: Vivek Goyal <vgoyal>
Date: Tue Feb 8 15:48:04 2022 -0500
virtiofsd: Fix breakage due to fuse_init_in size change
Kernel version 5.17 has increased the size of "struct fuse_init_in" struct.
Previously this struct was 16 bytes and now it has been extended to
64 bytes in size.
(In reply to Dr. David Alan Gilbert from comment #9) > I think the problem here is the kernel header update and we probably need to > pull in qemu's: > commit 776dc4b1650062099df3cb4f90fa01c8e73eecfa > Author: Vivek Goyal <vgoyal> > Date: Tue Feb 8 15:48:06 2022 -0500 > > virtiofsd: Parse extended "struct fuse_init_in" > > Add some code to parse extended "struct fuse_init_in". And use a local > variable "flag" to represent 64 bit flags. This will make it easier > to add more features without having to worry about two 32bit flags > (->flags > and ->flags2) in "fuse_struct_in". > > commit a086d54c6ffa38f7e71f182b63a25315304a3392 > Author: Vivek Goyal <vgoyal> > Date: Tue Feb 8 15:48:04 2022 -0500 > > virtiofsd: Fix breakage due to fuse_init_in size change > > Kernel version 5.17 has increased the size of "struct fuse_init_in" > struct. > Previously this struct was 16 bytes and now it has been extended to > 64 bytes in size. If kernel headers have been updated in latest qemu, then it makes sense to pull in these patches. We had realized that header updates will break things so we have first committed these patches upstream before header update. (In reply to Vivek Goyal from comment #5) > So, IIUC, qemu-kvm-core-6.2.0-14.module+el8.7.0+15289+26b4351e.x86_64 works > but qemu-kvm-6.2.0-15.module+el8.7.0+15644+189a21f6.x86_64 fails? Right? > While guest kernel remains the same on host and guest > (kernel-4.18.0-400.el8.x86_64(host/guest)). > > Please confirm. If that's true, it points to some change going in qemu. Yes, re-test with the same host kernel and guest kernel, qemu-kvm-core-6.2.0-15.module+el8.7.0+15644+189a21f6.x86_64 fail, while qemu-kvm-core-6.2.0-14.module+el8.7.0+15289+26b4351e.x86_64 works. Kernel 4.18.0-395.el8.x86_64(guest) kernel-4.18.0-398.el8.x86_64(host) Reproduce the similar issues on ppc64le on Power 8, so marked it as all architectures. kernel-4.18.0-400.el8.ppc64le qemu-kvm-6.2.0-15.module+el8.7.0+15644+189a21f6.ppc64le SLOF-20210217-1.module+el8.6.0+12861+13975d62.noarch Command line /usr/libexec/qemu-kvm -name vm3 -sandbox on -machine pseries -nodefaults -device VGA,bus=pci.0,addr=0x2 -device i6300esb,bus=pci.0,addr=0x3 -watchdog-action reset -device pci-bridge,id=pci_bridge,bus=pci.0,addr=0x4,chassis_nr=1 -m 4096 -object memory-backend-file,mem-path=/var/ram_vm3,share=yes,size=4G,id=mem-mem1 -smp 4,maxcpus=4,cores=2,threads=1,sockets=2 -numa node,memdev=mem-mem1,nodeid=0 -cpu host -chardev socket,wait=off,server=on,id=chardev_serial0,path=/tmp/ttt -device spapr-vty,id=serial0,reg=0x30000000,chardev=chardev_serial0 -object rng-random,filename=/dev/urandom,id=passthrough-1i0XOugg -device virtio-rng-pci,id=virtio-rng-pci-UW43yazK,rng=passthrough-1i0XOugg,bus=pci.0,addr=0x5 -device qemu-xhci,id=usb1,bus=pci.0,addr=0x6 -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 -blockdev node-name=file_image1,driver=file,auto-read-only=on,discard=unmap,aio=threads,filename=/home/kar/vt_test_images/rhel870-ppc64le-virtio-scsi.qcow2,cache.direct=on,cache.no-flush=off -blockdev node-name=drive_image1,driver=qcow2,read-only=off,cache.direct=on,cache.no-flush=off,file=file_image1 -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,write-cache=on,bus=pci.0,addr=0x7 -chardev socket,id=char_virtiofs_fs3,path=/tmp/virtiofsd.sock -device vhost-user-fs-pci,id=vufs_virtiofs_fs3,chardev=char_virtiofs_fs3,tag=myfs3,queue-size=1024,bus=pci_bridge,addr=0x1 -vnc :2 -rtc base=utc,clock=host -boot menu=off,order=cdn,once=c,strict=off -enable-kvm -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x9 -monitor stdio Actual results, [root@localhost ~]# mount -t virtiofs myfs3 /mnt/myfs3 mount -t virtiofs myfs3 /mnt/myfs3 [ 648.074252] SELinux: (dev virtiofs, type virtiofs) getxattr errno 111 mount: /mnt/myfs3: mount(2) system call failed: Connection refused. Hi David， Seems the merge request is ready to merge with label BZ Approved and Reviewer Done. https://gitlab.com/redhat/rhel/src/qemu-kvm/qemu-kvm/-/merge_requests/193 Could you please have check if it is ready to merge ? This bz block our gating test, lead to some other bugs pending as gating fail. Many thanks! Best regards Yanan Fu Hi Mirek， Could you please help merge it[1] if everything is ok ? [1]https://gitlab.com/redhat/rhel/src/qemu-kvm/qemu-kvm/-/merge_requests/193 Many Thanks! Best regards Yanan Fu (In reply to Yanan Fu from comment #18) > Hi David， > > Seems the merge request is ready to merge with label BZ Approved and > Reviewer Done. > https://gitlab.com/redhat/rhel/src/qemu-kvm/qemu-kvm/-/merge_requests/193 > > Could you please have check if it is ready to merge ? > > This bz block our gating test, lead to some other bugs pending as gating > fail. > Many thanks! > > Best regards > Yanan Fu Hi Dave, COU(In reply to Yanan Fu from comment #18) > Hi David， > > Seems the merge request is ready to merge with label BZ Approved and > Reviewer Done. > https://gitlab.com/redhat/rhel/src/qemu-kvm/qemu-kvm/-/merge_requests/193 > > Could you please have check if it is ready to merge ? > > This bz block our gating test, lead to some other bugs pending as gating > fail. > Many thanks! > > Best regards > Yanan Fu Hi Dave, as Yanan mentioned above this bug will block qemu-kvm component gating test, could you have a check the progress? Thanks in advance. Xiaoling (In reply to xiagao from comment #21) > (In reply to Yanan Fu from comment #18) > > Hi David， > > > > Seems the merge request is ready to merge with label BZ Approved and > > Reviewer Done. > > https://gitlab.com/redhat/rhel/src/qemu-kvm/qemu-kvm/-/merge_requests/193 > > > > Could you please have check if it is ready to merge ? > > > > This bz block our gating test, lead to some other bugs pending as gating > > fail. > > Many thanks! > > > > Best regards > > Yanan Fu > > Hi Dave, COU(In reply to Yanan Fu from comment #18) > > Hi David， > > > > Seems the merge request is ready to merge with label BZ Approved and > > Reviewer Done. > > https://gitlab.com/redhat/rhel/src/qemu-kvm/qemu-kvm/-/merge_requests/193 > > > > Could you please have check if it is ready to merge ? > > > > This bz block our gating test, lead to some other bugs pending as gating > > fail. > > Many thanks! > > > > Best regards > > Yanan Fu > > > Hi Dave, as Yanan mentioned above this bug will block qemu-kvm component > gating test, could you have a check the progress? > Thanks in advance. > Xiaoling I think it's just the maintainers handling the merge; moving needinfo to mrezanin QE bot(pre verify): Set 'Verified:Tested,SanityOnly' as gating/tier1 test pass. Run a virtiofs test loop,the result looks good, verify this bug. Test pkg: kernel-4.18.0-402.el8.x86_64 edk2-ovmf-20220126gitbb1bba3d77-2.el8.noarch qemu-kvm-6.2.0-16.module+el8.7.0+15743+c774064d.x86_64 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 (Low: 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:7472 |
Description of problem: # mount -t virtiofs myfs /mnt/a mount: /mnt/a: mount(2) system call failed: Connection refused. demsg info: SELinux: (dev virtiofs, type virtiofs) getxattr errno 111 # getenforce Enforcing Version-Release number of selected component (if applicable): kernel-4.18.0-400.el8.x86_64(host/guest) qemu-kvm-6.2.0-15.module+el8.7.0+15644+189a21f6.x86_64 How reproducible: 100% Steps to Reproduce: 1. start virtiofsd on rhel870 host # /usr/libexec/virtiofsd --socket-path=/tmp/virtiofsd.sock -o source=/home/test1,cache=always --debug virtio_session_mount: Waiting for vhost-user socket connection... virtio_session_mount: Received vhost-user socket connection virtio_loop: Entry fv_queue_set_started: qidx=0 started=1 fv_queue_thread: Start for queue 0 kick_fd 9 fv_queue_set_started: qidx=1 started=1 fv_queue_thread: Start for queue 1 kick_fd 12 2. boot up rhel870 guest with virtiofs device -m 4096 \ -object memory-backend-file,mem-path=/dev/shm,share=yes,size=4G,id=mem-mem1 \ -chardev socket,id=char_virtiofs_fs,path=/tmp/virtiofsd.sock \ -device pcie-root-port,id=pcie-root-port-4,port=0x4,addr=0x1.0x4,bus=pcie.0,chassis=5 \ -device vhost-user-fs-pci,id=vufs_virtiofs_fs,chardev=char_virtiofs_fs,tag=myfs,queue-size=1024,bus=pcie-root-port-4,addr=0x0 \ 3. mount virtiofs in guest. Actual results: # mount -t virtiofs myfs /mnt/a mount: /mnt/a: mount(2) system call failed: Connection refused. demsg info: SELinux: (dev virtiofs, type virtiofs) getxattr errno 111 Expected results: mount successfully Additional info: