A mounted mqueuefs crashes when removing queue as user. To reproduce: $ sudo mount -t mqueuefs none /mnt $ sudo touch /mnt/queue1 $ sudo rm -f /mnt/queue1 This only seems to crash on -CURRENT as I couldn't reproduce on -RELEASE or -STABLE. You can use the QEMU VM at https://download.freebsd.org/snapshots/VM-IMAGES/15.0-CURRENT/amd64/Latest/FreeBSD-15.0-CURRENT-amd64-ufs.qcow2.xz dmesg log: Fatal trap 9: general protection fault while in kernel mode cpuid = 1; apic id = 01 instruction pointer = 0x20:0xffffffff80ba8aae stack pointer = 0x28:0xfffffe0068c12e50 frame pointer = 0x28:0xfffffe0068c12ec0 code segment = base rx0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (thread taskq) rdi: deadc0dedeadc0de rsi: 000000000000c0de rdx: 0000000000000000 rcx: 0000000000000001 r8: 0000000000000001 r9: 0000000000000000 rax: 0000000000000001 rbx: fffff800034f6400 rbp: fffffe0068c12ec0 r10: 0000000000010000 r11: 0000000000000001 r12: 0000000000000001 r13: 000000000000c0de r14: fffff800034f6458 r15: fffff80104001020 trap number = 9 panic: general protection fault cpuid = 1 time = 1715530856 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0068c12b90 vpanic() at vpanic+0x13f/frame 0xfffffe0068c12cc0 panic() at panic+0x43/frame 0xfffffe0068c12d20 trap_fatal() at trap_fatal+0x40b/frame 0xfffffe0068c12d80 calltrap() at calltrap+0x8/frame 0xfffffe0068c12d80 --- trap 0x9, rip = 0xffffffff80ba8aae, rsp = 0xfffffe0068c12e50, rbp = 0xfffffe0068c12ec0 --- taskqueue_run_locked() at taskqueue_run_locked+0x1be/frame 0xfffffe0068c12ec0 taskqueue_thread_loop() at taskqueue_thread_loop+0xd3/frame 0xfffffe0068c12ef0 fork_exit() at fork_exit+0x82/frame 0xfffffe0068c12f30 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0068c12f30 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- KDB: enter: panic
*** Bug 278937 has been marked as a duplicate of this bug. ***
The crash doesn't happen when I include "std.nodebug" in my kernel config. But I also tried by removing taskqueue_enqueue call, not seen in synthetic filesystems, and it works. PR at https://github.com/freebsd/freebsd-src/pull/1249
I managed to crash -STABLE (didn't try -RELEASE) like this: $ sudo mount -t mqueuefs none /mnt $ touch /mnt/{1..101} # Needs Bash I think touch: /mnt/101: Resource temporarily unavailable $ sysctl kern.mqueue kern.mqueue.curmq: 100 kern.mqueue.maxmq: 100 kern.mqueue.maxmsgsize: 16384 kern.mqueue.maxmsg: 100 $ rm -f /mnt/* $ sysctl kern.mqueue kern.mqueue.curmq: 0 kern.mqueue.maxmq: 100 kern.mqueue.maxmsgsize: 16384 kern.mqueue.maxmsg: 100 $ for i in {1..101} ; do posixmqcontrol create -d /$i -s 1 -d 1; done posixmqcontrol: mq_open(create): Too many open files in system $ rm -f /mnt/* POSIX message queues seem broken on FreeBSD. There's no limit per-user. I tried this on Linux and it only allowed me to create only 10 messages queues as user, without limiting root.
The command for creating mq's above: $ for i in {1..101} ; do posixmqcontrol create -q /$i -s 1 -d 1; done
https://reviews.freebsd.org/D45305