Since https://reviews.freebsd.org/D56675 got merged to stable/15, releng/15.1 and main I've have consistent kernel panics when running some workloads under /compat/linux. The backtrace is: #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57 #1 doadump (textdump=<optimized out>) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0xffffffff80b86539 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:519 #3 0xffffffff80b86a47 in vpanic (fmt=0xffffffff811f8a11 "%s", ap=ap@entry=0xfffffe0203f59a40) at /usr/src/sys/kern/kern_shutdown.c:974 #4 0xffffffff80b86873 in panic (fmt=<unavailable>) at /usr/src/sys/kern/kern_shutdown.c:887 #5 0xffffffff81097fcd in trap_fatal (frame=<optimized out>, eva=<optimized out>) at /usr/src/sys/amd64/amd64/trap.c:1028 #6 0xffffffff81097fcd in trap_pfault (frame=0xfffffe0203f59ac0, usermode=false, signo=<optimized out>, ucode=<optimized out>) #7 <signal handler called> #8 0xffffffff80c40309 in uipc_ctloutput (so=<optimized out>, sopt=<optimized out>) at /usr/src/sys/kern/uipc_usrreq.c:2762 #9 0xffffffff80c3579f in sogetopt (so=0xfffffe0203f59c28, sopt=sopt@entry=0xfffffe0203f59ce8) at /usr/src/sys/kern/uipc_socket.c:4098 #10 0xffffffff80c3ab85 in kern_getsockopt (td=td@entry=0xfffff80507c98000, s=<optimized out>, level=level@entry=0, name=name@entry=1, val=val@entry=0xfffffe0203f59d60, valseg=valseg@entry=UIO_SYSSPACE, valsize=0xfffffe0203f59dd4) at /usr/src/sys/kern/uipc_syscalls.c:1330 #11 0xffffffff845986ac in linux_getsockopt (td=0xfffff80507c98000, args=0xfffff80507c98428) at /usr/src/sys/compat/linux/linux_socket.c:2301 #12 0xffffffff81098606 in syscallenter (td=0xfffff80507c98000) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:193 #13 amd64_syscall (td=0xfffff80507c98000, traced=0) at /usr/src/sys/amd64/amd64/trap.c:1267 #14 <signal handler called> #15 0x0000000801310d2e in ?? () Backtrace stopped: Cannot access memory at address 0x88398db68 For reference this happens to me when running unit tests in java 21 under /compat/linux (base rl9). If there's a need I can attach the dumps to the ticket (or share it otherwise). Regards.
Thanks for reporting. Can you offer any better steps to reproduce the problem? How can I install and run said unit tests?
Created attachment 270789 [details] sample-maven-project
Hi Alan, So, on /compat/linux you will have to install at least java-21-openjdk and maven-openjdk21. I've installed dnf on rocky linux to install these as there isn't any freebsd packages that do this. But it may be possible to trigger this with for example a debian based /compat/linux. Assuming you have java and maven, you just need to execute: "mvn clean install" in the main folder (where you have the app and openapi folders from the attached zip file). I'm sorry but I've not encountered this issue any other way (but haven't done much testing). If you have any other tests that I can run that will help let me know. Thanks
I'm not a Java programmer. You'll have to provide instructions for how to compile and run that project. Also, it looks huge. Can you make a minimal example instead of giving me your entire project?
I can try to reduce the size (will get back to you later, have to leave now), in terms of instructions that's it, assuming you have java and maven installed it's executing 'mvn clean install' on the root project folder. Please note that due to differences in support this will not run with the FreeBSD native packages of openjdk21/maven. I'll try to see if I can reproduce another way that's simpler. Regards
If my last comment seemed a bit short, I apologize. It's because comments 3 and 4 crossed in the ether. I'm going to install a Debian jail and try to reproduce this without Java first.
I was able to reproduce the problem without Java, by running a small Rust binary within a Linux jail. What I did was: 1) Create a Debian Trixie jail according to the instructions at https://iocage.readthedocs.io/en/latest/debian.html 2) Cloned the Nix repository from https://github.com/nix-rust/nix.git 3) Built the Nix tests in a Linux VM. I probably could've used the Linux jail, but I already had the VM setup for this task. - cd /path/to/nix - cargo test --all-features 4) Transferred the test binary into the Linux jail. In this case, the test binary is named /path/to/nix/target/debug/deps/test-5cc4bc3ec691ad64 5) Executed the Linux binary like this: - sudo iocage exec debjail /tmp/test-5cc4bc3ec691ad64 can_get_peercred_on_unix_socket The result was a kernel panic that looked the same as the OP's. I'll work on a fix, using this reproduction method.
Alan, no probelm. I know that my use case is just that. Glad you could find a more easy way to reproduce the issue. If you need some extra testing from my side just let me know. Regards
Miguel, if you have the time, could you please test the change in the linked code review?
Alan, Assuming I didn't mess up building the kernel your patch works and I no longer have the kernel panic. For reference I've patched stable/15 and am assuming the same fix works correctly on releng/15.1. Thanks for the quick turn-around. Regards
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=4cee16d471d47f4673e4d2c66f7a96d4e6d86ee9 commit 4cee16d471d47f4673e4d2c66f7a96d4e6d86ee9 Author: Alan Somers <asomers@FreeBSD.org> AuthorDate: 2026-05-16 18:03:49 +0000 Commit: Alan Somers <asomers@FreeBSD.org> CommitDate: 2026-05-17 12:49:23 +0000 linuxulator: fix SO_PEERCRED emulation after 1d24638d3e8 For Linux binaries, sopt->sopt_td may be null. And there's also no need to check it, since struct l_ucred has the same layout on 32-bit systems as on 64-bit ones. PR: 295333 Reported by: Miguel Gomes <miguel.dias.gomes@protonmail.com> Fixes: 1d24638d3e8 ("Fix LOCAL_PEERCRED in 32-bit compat mode") MFC after: 3 days Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D57032 sys/kern/uipc_usrreq.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
Thanks for testing it, Miguel. I committed to main just now, and I'll MFC on Wednesday.
A commit in branch stable/15 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=57fb48f8e2fca5f069e9bc3cf080608f602919a9 commit 57fb48f8e2fca5f069e9bc3cf080608f602919a9 Author: Alan Somers <asomers@FreeBSD.org> AuthorDate: 2026-05-16 18:03:49 +0000 Commit: Alan Somers <asomers@FreeBSD.org> CommitDate: 2026-05-20 01:28:33 +0000 linuxulator: fix SO_PEERCRED emulation after 1d24638d3e8 For Linux binaries, sopt->sopt_td may be null. And there's also no need to check it, since struct l_ucred has the same layout on 32-bit systems as on 64-bit ones. PR: 295333 Reported by: Miguel Gomes <miguel.dias.gomes@protonmail.com> Fixes: 1d24638d3e8 ("Fix LOCAL_PEERCRED in 32-bit compat mode") Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D57032 (cherry picked from commit 4cee16d471d47f4673e4d2c66f7a96d4e6d86ee9) sys/kern/uipc_usrreq.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
A commit in branch releng/15.1 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=4eb969321cefdc878de8be81abd30d09732db7c9 commit 4eb969321cefdc878de8be81abd30d09732db7c9 Author: Alan Somers <asomers@FreeBSD.org> AuthorDate: 2026-05-16 18:03:49 +0000 Commit: Colin Percival <cperciva@FreeBSD.org> CommitDate: 2026-05-21 21:21:00 +0000 linuxulator: fix SO_PEERCRED emulation after 1d24638d3e8 For Linux binaries, sopt->sopt_td may be null. And there's also no need to check it, since struct l_ucred has the same layout on 32-bit systems as on 64-bit ones. Approved by: re (cperciva) PR: 295333 Reported by: Miguel Gomes <miguel.dias.gomes@protonmail.com> Fixes: 1d24638d3e8 ("Fix LOCAL_PEERCRED in 32-bit compat mode") Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D57032 (cherry picked from commit 4cee16d471d47f4673e4d2c66f7a96d4e6d86ee9) (cherry picked from commit 57fb48f8e2fca5f069e9bc3cf080608f602919a9) sys/kern/uipc_usrreq.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)