Comment 1 Dmitry Chagin 2023-10-17 20:46:29 UTC

bt doesn't look fresh, can it be repeated with a latest HEAD?

Comment 2 Edward Tomasz Napierala 2023-10-18 10:52:16 UTC

Sure; looks the same to me:

FreeBSD pustak 15.0-CURRENT FreeBSD 15.0-CURRENT #69 main-n266018-d2abbfede534-dirty: Wed Oct 18 11:33:02 BST 2023     root@pustak:/usr/obj/usr/home/trasz/git/freebsd-src/amd64.amd64/sys/GENERIC  amd64

panic: vrefact: wrong use count 0

GNU gdb (GDB) 13.2 [GDB v13.2 for FreeBSD]
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd15.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...
Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug...

Unread portion of the kernel message buffer:
VNASSERT failed: old > 0 not true at /usr/home/trasz/git/freebsd-src/sys/kern/vfs_subr.c:3367 (vrefact)
0xfffff8020f4eb380: type VCHR state VSTATE_CONSTRUCTED op 0xffffffff816ae700
    usecount 1, writecount 0, refcount 9 seqc users 0 rdev 0xfffff800095e4400
    hold count flags ()
    flags ()
    lock type devfs: UNLOCKED
	dev drm/128
panic: vrefact: wrong use count 0
cpuid = 2
time = 1697626072
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00f5c63820
vpanic() at vpanic+0x132/frame 0xfffffe00f5c63950
panic() at panic+0x43/frame 0xfffffe00f5c639b0
vrefact() at vrefact+0x5e/frame 0xfffffe00f5c639d0
fgetvp_lookup() at fgetvp_lookup+0x97/frame 0xfffffe00f5c63a30
namei_setup() at namei_setup+0x1bf/frame 0xfffffe00f5c63a80
namei_emptypath() at namei_emptypath+0x49/frame 0xfffffe00f5c63ae0
namei() at namei+0x686/frame 0xfffffe00f5c63b40
linux_kern_statat() at linux_kern_statat+0x101/frame 0xfffffe00f5c63c70
linux_newfstatat() at linux_newfstatat+0x59/frame 0xfffffe00f5c63e00
amd64_syscall() at amd64_syscall+0x153/frame 0xfffffe00f5c63f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe00f5c63f30
--- syscall (262, Linux ELF64, linux_newfstatat), rip = 0x801513f2e, rsp = 0x7fffffffc0b8, rbp = 0x1090540 ---
Uptime: 5m1s
Dumping 1061 out of 16225 MB:..2%..11%..22%..31%..41%..52%..61%..71%..82%..91%

__curthread ()
    at /usr/home/trasz/git/freebsd-src/sys/amd64/include/pcpu_aux.h:57
57		__asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu,
(kgdb) #0  __curthread ()
    at /usr/home/trasz/git/freebsd-src/sys/amd64/include/pcpu_aux.h:57
#1  doadump (textdump=textdump@entry=1)
    at /usr/home/trasz/git/freebsd-src/sys/kern/kern_shutdown.c:405
#2  0xffffffff80b4eeb0 in kern_reboot (howto=260)
    at /usr/home/trasz/git/freebsd-src/sys/kern/kern_shutdown.c:526
#3  0xffffffff80b4f3af in vpanic (
    fmt=0xffffffff811e494a "%s: wrong use count %d", 
    ap=ap@entry=0xfffffe00f5c63990)
    at /usr/home/trasz/git/freebsd-src/sys/kern/kern_shutdown.c:970
#4  0xffffffff80b4f153 in panic (fmt=<unavailable>)
    at /usr/home/trasz/git/freebsd-src/sys/kern/kern_shutdown.c:894
#5  0xffffffff80c45d3e in vrefact (vp=<optimized out>)
    at /usr/home/trasz/git/freebsd-src/sys/kern/vfs_subr.c:3367
#6  0xffffffff80aee297 in fgetvp_lookup (fd=<optimized out>, 
    ndp=ndp@entry=0xfffffe00f5c63b50, vpp=vpp@entry=0xfffffe00f5c63ac8)
    at /usr/home/trasz/git/freebsd-src/sys/kern/kern_descrip.c:3095
#7  0xffffffff80c3653f in namei_setup (ndp=ndp@entry=0xfffffe00f5c63b50, 
    dpp=dpp@entry=0xfffffe00f5c63ac8, pwdp=pwdp@entry=0xfffffe00f5c63ac0)
    at /usr/home/trasz/git/freebsd-src/sys/kern/vfs_lookup.c:363
#8  0xffffffff80c361b9 in namei_emptypath (ndp=ndp@entry=0xfffffe00f5c63b50)
    at /usr/home/trasz/git/freebsd-src/sys/kern/vfs_lookup.c:443
#9  0xffffffff80c35fc6 in namei (ndp=ndp@entry=0xfffffe00f5c63b50)
    at /usr/home/trasz/git/freebsd-src/sys/kern/vfs_lookup.c:664
#10 0xffffffff83b447d1 in linux_kern_statat (td=0xfffffe00dc405000, 
    flag=16384, fd=4, 
    path=0x8015d846f <error: Cannot access memory at address 0x8015d846f>, 
    pathseg=UIO_USERSPACE, sbp=sbp@entry=0xfffffe00f5c63c88)
    at /usr/home/trasz/git/freebsd-src/sys/compat/linux/linux_stats.c:103
#11 0xffffffff83b44519 in linux_newfstatat (td=<unavailable>, 
    args=0xfffffe00dc405400)
    at /usr/home/trasz/git/freebsd-src/sys/compat/linux/linux_stats.c:606
#12 0xffffffff810506a3 in syscallenter (td=0xfffffe00dc405000)
    at /usr/home/trasz/git/freebsd-src/sys/amd64/amd64/../../kern/subr_syscall.c:188
#13 amd64_syscall (td=0xfffffe00dc405000, traced=0)
    at /usr/home/trasz/git/freebsd-src/sys/amd64/amd64/trap.c:1194
#14 <signal handler called>
#15 0x0000000801513f2e in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffffffc0b8
(kgdb)

I get the same panic. It's reproducible with:

#define _GNU_SOURCE

#include <assert.h>
#include <stdio.h>
#include <fcntl.h>
#include <sys/stat.h>

int main() {
  int fd = open("/dev/dri/card0", O_RDWR | O_CLOEXEC);
  assert(fd != -1);

  struct stat st;
  fstatat(fd, "", &st, AT_EMPTY_PATH);

  return 0;
}

Comment 4 Edward Tomasz Napierala 2024-11-01 15:17:34 UTC

https://reviews.freebsd.org/D47391

Comment 5 commit-hook 2024-11-13 10:29:30 UTC

A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=fc595a6b76642dfdfdb8e6f9b9bbc734e95fb59c

commit fc595a6b76642dfdfdb8e6f9b9bbc734e95fb59c
Author:     Edward Tomasz Napierala <trasz@FreeBSD.org>
AuthorDate: 2024-11-13 10:00:38 +0000
Commit:     Edward Tomasz Napierala <trasz@FreeBSD.org>
CommitDate: 2024-11-13 10:25:57 +0000

    Fix "vrefact: wrong use count 0" with DRM

    Bump the vnode use count, not its hold count. This fixes a panic triggered
    by fstatat(..., AT_EMPTY_PATH) on DRM device nodes, which happens to be
    what glxinfo(1) from Ubuntu Jammy is doing.

    PR:             kern/274538
    Reviewed By:    kib (earlier version), olce
    Differential Revision:  https://reviews.freebsd.org/D47391

 sys/compat/linuxkpi/common/src/linux_compat.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)