Date: Wed, 10 Aug 2022 15:29:57 +0000 From: bugzilla-noreply@freebsd.org To: virtualization@FreeBSD.org Subject: [Bug 265749] bhyve NVMe emulation after LLVM 14 import to CURRENT Message-ID: <bug-265749-27103-ULNBB9MiMH@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-265749-27103@https.bugs.freebsd.org/bugzilla/> References: <bug-265749-27103@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D265749 Mark Johnston <markj@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Open CC| |markj@FreeBSD.org --- Comment #1 from Mark Johnston <markj@FreeBSD.org> --- On my system, bhyve segfaults after printing nvme_opc_write_read command would exceed LBA range(slba=3D0x2ffff0 nblocks= =3D0x1) If I disassemble nvme_opc_write_read(), the end of the function (inlined in= to pci_nvme_write()) is: 0x000000000106bfb3 <+7763>: jmp 0x106bfbc <pci_nvme_write+7772> 0x000000000106bfb5 <+7765>: lea -0x3b292(%rip),%rsi # 0x1030d= 2a 0x000000000106bfbc <+7772>: lea -0x4008a(%rip),%rdx # 0x102bf= 39 0x000000000106bfc3 <+7779>: mov %r9,%rcx 0x000000000106bfc6 <+7782>: xor %eax,%eax 0x000000000106bfc8 <+7784>: call 0x1086010 <fprintf@plt> End of assembler dump. and that fprintf() call is the warning. If I disassemble past that, I get (gdb) x/16i 0x000000000106bfc8 0x106bfc8 <pci_nvme_write+7784>: call 0x1086010 <fprintf@plt> =3D> 0x106bfcd: nopl (%rax) 0x106bfd0 <pci_nvme_read>: push %rbp 0x106bfd1 <pci_nvme_read+1>: mov %rsp,%rbp 0x106bfd4 <pci_nvme_read+4>: push %r15 0x106bfd6 <pci_nvme_read+6>: push %r14 0x106bfd8 <pci_nvme_read+8>: push %r13 so we're just running off the end of the function and going into pci_nvme_read(). That's pretty weird! I thought the compiler would insert breakpoints between functions. Maybe there is some UB happening here, but compiling bhyve with UBSAN makes= the problem go away. We compile bhyve with many warnings disabled; enabling th= em for pci_nvme.c uncovers some actual bugs, but fixing them doesn't fix the problem. And it's really bizarre that the compiler is apparently assuming = that fprintf() won't return. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-265749-27103-ULNBB9MiMH>