I ran the unions test cases in a loop for 7 hours, with this patch.
Looks good to me.

PS
Feel free to fix or add any unionfs tests you like.

Looks good to me.

In D58264#1344459, @kib wrote:

In D58264#1344458, @pho wrote:

I am, although it seems strange that I was not able to reproduce Mark's zombie issue.

It is not completely unexpected. I did a change right after the Mark' report, which fixed one zombie leak.

In D58264#1344457, @kib wrote:

In D58264#1344442, @kib wrote:

In D58264#1344441, @pho wrote:

In D58264#1343336, @kib wrote:

In D58264#1343328, @markj wrote:

I ran the full regression test suite with the three patches applied, and got an OOM somewhere in the network tests. I can see a zombie leak somewhere, running the test again I see:

6441 threads:  19 running, 834 sleeping, 4960 zombie, 628 waiting

and the zombie count is growing slowly.

Could you please print out p_zombierefs for several of such zombies?
BTW one of the changes that I upload shortly might fix it, but I am not sure.

I will ask pho to help with the reproduction.

I ran most of the stress2 tests plus the tests in /usr/tests, without seeing any zombie leaks. This on ufs-dd72f46f512f.

Sorry, do you mean the ufs branch from the deviant3? It does not have these changes.

Could you please give the pdrfork branch some run time?

Great. So are you fine with the 'Tested by: pho' for this series?

In D58264#1344442, @kib wrote:

In D58264#1344441, @pho wrote:

In D58264#1343336, @kib wrote:

In D58264#1343328, @markj wrote:

I ran the full regression test suite with the three patches applied, and got an OOM somewhere in the network tests. I can see a zombie leak somewhere, running the test again I see:

6441 threads:  19 running, 834 sleeping, 4960 zombie, 628 waiting

and the zombie count is growing slowly.

Could you please print out p_zombierefs for several of such zombies?
BTW one of the changes that I upload shortly might fix it, but I am not sure.

I will ask pho to help with the reproduction.

I ran most of the stress2 tests plus the tests in /usr/tests, without seeing any zombie leaks. This on ufs-dd72f46f512f.

Sorry, do you mean the ufs branch from the deviant3? It does not have these changes.

Could you please give the pdrfork branch some run time?

In D58264#1343336, @kib wrote:

In D58264#1343328, @markj wrote:

I ran the full regression test suite with the three patches applied, and got an OOM somewhere in the network tests. I can see a zombie leak somewhere, running the test again I see:

6441 threads:  19 running, 834 sleeping, 4960 zombie, 628 waiting

and the zombie count is growing slowly.

Could you please print out p_zombierefs for several of such zombies?
BTW one of the changes that I upload shortly might fix it, but I am not sure.

I will ask pho to help with the reproduction.

Looks good to me. I have started a full stress2 test, just in case ..

09:54 /usr/src/tools/test/stress2/misc $ ./filemount_panic.sh
  PID COMM                OSREL PATH
67825 cover             1600019 /tmp/tmp.kEEk4GCRkj.renamed/cover
09:54 /usr/src/tools/test/stress2/misc $ ./filemount_panic2.sh 
mounted /bin/sleep over /tmp/filemount.VWEd7r/cover
querying kern.proc.pathname for pid 28160
pathname = /tmp/filemount.VWEd7r.renamed/cover
09:56 /usr/src/tools/test/stress2/misc $ uname -a
FreeBSD mercat1.netperf.freebsd.org 16.0-CURRENT FreeBSD 16.0-CURRENT #1 ufs-n287721-3b23d05c7781: Tue Jul 28 08:09:01 CEST 2026     pho@mercat1.netperf.freebsd.org:/var/tmp/deviant3/sys/amd64/compile/PHO amd64
09:56 /usr/src/tools/test/stress2/misc $

I no longer get a panic with the two test scenarios and D58178.id181841.diff added..

Yes, thank you!
Reproduced: https://people.freebsd.org/~pho/stress/log/log0679.txt

In D58178#1341511, @nick_spun.io wrote:

Here are two new clean reproducers for this panic - there is also another panic doing mount_nullfs -o mountdir $(mktemp) (using -o mountdir on top of a file) but that is outside of this scope.

filemount_panic.sh1 KBDownload

filemount_panic.c3 KBDownload

I ran all of the stress2 tests without seeing any issues.

I ran a full stress2 test without seeing any issues.

20260228 20:28:50 all (1/11): ftruncate3.sh
VNASSERT failed: a->a_gen.a_desc == &vop_lock1_desc not true at vnode_if.c:2095 (VOP_LOCK1_APV)
0xfffffe016a9e6940: type VREG state VSTATE_CONSTRUCTED op 0xffffffff81aaead8
    usecount 3, writecount 2, refcount 1 seqc users 0
    hold count flags ()
    flags (VV_VMSIZEVNLOCK|VI(0x40)|VMP_LAZYLIST)
    v_object 0xfffff803dac10c30 ref 2 pages 0 cleanbuf 0 dirtybuf 0
    lock type nfs: UNLOCKED
#0 0xffffffff80b990c8 at lockmgr_lock_flags+0x1b8
#1 0xffffffff80cc0f20 at vop_sigdefer+0x30
#2 0xffffffff81213a93 at VOP_LOCK1_APV+0x133
#3 0xffffffff80cfc96b at VOP_LOCK1+0x4b
#4 0xffffffff80cfa260 at _vn_lock+0x140
#5 0xffffffff80cf7902 at vn_truncate+0x82
#6 0xffffffff80c4febe at kern_ftruncate+0xee
#7 0xffffffff8113eaa9 at amd64_syscall+0x169
#8 0xffffffff8110d6db at fast_syscall_common+0xf8
	fileid 3 fsid 0x3a3a00ff01
panic: Wrong a_desc in vop_lock1(0xfffffe016a9e6940, 0xfffffe010008fa50)

log0657.txt

In D55562#1271443, @ngie wrote:

My MacBookPro13,1 no longer panics when I run sysctl dev.pci..

@pho : would it make sense to make this a regression test?

I have completed a full stress2 test run without seeing any issues. This on the pdrfork-5982326ec607 branch.

I ran the full set of stress2 tests, without seeing any issues.

I ran the full set of stress2 tests, without seeing any issues.

LGTM

D53988.167397.patch also LGTM

I ran the uniofs tests in a loop for 5 hours without observing any issues.

In D53666#1226326, @christos wrote:

Do what I explained in the last message. stress2 has finished after 30 minutes
without panicking. I've yet to test chn_read() though.

@pho, can you also test please?

I ran tests with D51085.id157729.diff for 18 hours without seeing any issues.

In D50482#1153552, @kib wrote:

There seems to be no more interest to the review.
Peter, could you, please run the stress2 set, all amd64 and threading tests are relevant?

I ran fsck tests with D50520.156022.patch added, without observing any issues.

I have been running tests with D50392.155617.patch for 13 hours without seeing any issues

In D50200#1145706, @olce wrote:

In D50200#1145643, @pho wrote:

Looks good to me.

Great. Sorry, I committed this quite quickly as it's a very small change that I'd like to be MFCed soon and put into 14.3, else I would have waited more for you.

Looks good to me.

I ran tests with D47114.154425.patch for 5 hours without seeing any issues.

I ran the syzkaller reproducer for an hour with D49987.154201.patch added. I added a further 4 hours of random test cases.
I did not observe any issues.

Doug,
I have mailed you the test scenario. I will start a test on the latest version of HEAD.

In D49957#1139554, @dougm wrote:

In D49957#1139502, @pho wrote:

The syzkaller test still triggers a panic:

20250422 20:52:41 all (1/1): syzkaller75.sh

I don't have access to syzkaller75.sh. Can you provide it?

The syzkaller test still triggers a panic:

I got this panic, which seems unrelated to me, after 8 hours of testing:

I completed a full stress2 test run with D49103.151425.patch without seeing any issues.

I got this with D49103.151389.patch:

20250224 11:38:23 all (254/953): mmap8.sh
panic: vm_reserv_from_object: msucc doesn't succeed pindex
cpuid = 4
time = 1740393505
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe01087809b0
vpanic() at vpanic+0x136/frame 0xfffffe0108780ae0
panic() at panic+0x43/frame 0xfffffe0108780b40
vm_reserv_from_object() at vm_reserv_from_object+0xc9/frame 0xfffffe0108780b50
vm_reserv_alloc_page() at vm_reserv_alloc_page+0x72/frame 0xfffffe0108780bb0
vm_page_alloc_domain_after() at vm_page_alloc_domain_after+0x140/frame 0xfffffe0108780c40
vm_page_alloc_after() at vm_page_alloc_after+0x54/frame 0xfffffe0108780cb0
vm_fault_copy_entry() at vm_fault_copy_entry+0x32f/frame 0xfffffe0108780d60
vm_map_protect() at vm_map_protect+0x72b/frame 0xfffffe0108780df0
sys_mprotect() at sys_mprotect+0x9f/frame 0xfffffe0108780e00
amd64_syscall() at amd64_syscall+0x15a/frame 0xfffffe0108780f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0108780f30
--- syscall (74, FreeBSD ELF64, mprotect), rip = 0x822c0ed7a, rsp = 0x820d0ee78, rbp = 0x820d0eea0 ---
KDB: enter: panic
[ thread pid 82131 tid 102074 ]
Stopped at      kdb_enter+0x33: movq    $0,0x104ed52(%rip)
db>

It's easy to reproduce on my test box.

I ran tests for two days on D49103.151334.patch. Switching to D49103.151389.patch

I ran tests with D48588.150722.patch for two days without observing any problems.

I ran all of the stress2 tests using nullfs and also ronald@'s test scenario. LGTM.

FYI: I came across this i386 problem after commit 0078df5f0258.

Trying to mount root from ufs:/dev/vtbd0p1 [rw]...
WARNING: WITNESS option enabled, expect reduced performance.
WARNING: DIAGNOSTIC option enabled, expect reduced performance.
WARNING: 32-bit kernels are deprecated and may be removed in FreeBSD 15.0.
panic: vm_page_t 0x5d49be0 phys_addr mismatch ffffffffb8779000 00000000b8779405
cpuid = 3
time = 1738177579
KDB: stack backtrace:
db_trace_self_wrapper(7,114beb40,5d49be0,ffffffff,ffffffff,...) at db_trace_self_wrapper+0x28/frame 0x113f6744
vpanic(148badd,113f6780,113f6780,113f67f0,13a54e9,...) at vpanic+0xf4/frame 0x113f6760
panic(148badd,5d49be0,b8779000,ffffffff,b8779405,...) at panic+0x14/frame 0x113f6774
pmap_pae_remove_pages(114128e8) at pmap_pae_remove_pages+0x599/frame 0x113f67f0
exec_new_vmspace(113f6994,188247c) at exec_new_vmspace+0x1cb/frame 0x113f6810
exec_elf32_imgact(113f6994,16d4801,113f6984,0,0,...) at exec_elf32_imgact+0x5e4/frame 0x113f6874
kern_execve(114beb40,113f6a8c,0,1141284c) at kern_execve+0x72c/frame 0x113f6a74
sys_execve(114beb40,114bedf0,114beb40,13ae913,114bede4,...) at sys_execve+0x4e/frame 0x113f6ac8
syscall(113f6ba8,3b,3b,3b,402aaf,...) at syscall+0x1e6/frame 0x113f6b9c
Xint0x80_syscall() at 0xffc03479/frame 0x113f6b9c
--- syscall (59, FreeBSD ELF32, execve), eip = 0x47e53f, esp = 0xffbfe848, ebp = 0xffbfe858 ---
KDB: enter: panic
[ thread pid 17 tid 100080 ]
Stopped at      kdb_enter+0x34: movl    $0,kdb_why
db> x/s version
version:        FreeBSD 15.0-CURRENT #0 main-n275068-0078df5f0258-dirty: Wed Jan 29 18:44:45 CET 2025\012    pho@mercat1.netperf.freebsd.org:/mnt25/obj/usr/src/i386.i386/sys/PHO\012
db>

With this patch I caught this:

I ran tests. for a day with D45409.149981.patch. LGTM.

In D47875#1092294, @des wrote:

I only needed to run tmpfs24 which does not use $testuser but refuses to run if it is not defined. This patch does not fix every broken test, but it fixes some of them.

In D47876#1092295, @des wrote:

Look again. There _is_ a hole at the end of the file.

I'm puzzled by how your change could work for you.

In D47876#1091689, @des wrote:

In D47876#1091682, @pho wrote:

I too have been thinking about removing the "Missing EOF hole" comment, but stalled because I still am not sure that the output is correct.
Isn't there supposed to be a virtual hole at the end of a file?

Only if there isn't already a hole there.

$ /tmp/lsholes tmpfs24.sh 
Min hole size is 512, file size is 2382.
data #1 @ 0, size=2382)
hole #2 @ 2382, size=0

I too have been thinking about removing the "Missing EOF hole" comment, but stalled because I still am not sure that the output is correct.
Isn't there supposed to be a virtual hole at the end of a file? See for example https://docs.oracle.com/cd/E86824_01/html/E54765/lseek-2.html

That does not work for me. This is what I get on a pristine install:

I completed a full stress2 test without seing any issues.

I do net see any panics with D47559.146396.patch

I ran all of the stress2 SU+J tests without seeing any issues with this patch.

In D47200#1076295, @pho wrote:

I'm running tests with both D47150.145188.patch and D47200.145189.patch. I'll be running a full set of stress2 tests, which takes about 60 hours.
No problems seen in the first 8 hours.

In D47150#1076296, @pho wrote:

I'm running tests with both D47150.145188.patch and D47200.145189.patch. I'll be running a full set of stress2 tests, which takes about 60 hours.
No problems seen in the first 8 hours.

I'm running tests with both D47150.145188.patch and D47200.145189.patch. I'll be running a full set of stress2 tests, which takes about 60 hours.
No problems seen in the first 8 hours.

I'm running tests with both D47150.145188.patch and D47200.145189.patch. I'll be running a full set of stress2 tests, which takes about 60 hours.
No problems seen in the first 8 hours.