Restore writecount tracking on unionfs vnode, in simplified form

In D33611#759740, @kib wrote:

In D33611#759655, @jah wrote:

Ok, will do. On a related note, I did test nullfs enough to know that it doesn't have the same panic-on-process-termination issue as unionfs. So for nullfs the text ref seems to be managed on the correct vnode even though nullfs also does not implement VOP_[UN]SET_TEXT.
I assume this is because of null_bypass? If so would it be sufficient to simply delete null_add_writecount?

Yes, null_bypass results in text references go onto the lower vnode.

I mostly agree with the note that maintaining writecount on the upper vnode is effectively nop. So I am interested in see if nullfs can work without it, and indeed for nullfs the corresponding change would be to remove the custom bypass.

In D33611#759601, @kib wrote:

In D33611#759589, @jah wrote:

In D33611#759420, @kib wrote:

Did you tried similar change for nullfs?

Basically text ref count needs to exist at least on the vnode which owns the actual v_object.

I haven't tried any nullfs changes, but the thought did occur to me since the unionfs code I changed was obviously copied from nullfs.
Would you like me to change nullfs as well (in a separate commit of course)?

Yes, and in fact I think that nullfs should be done first.

In D33611#759420, @kib wrote:

Did you tried similar change for nullfs?

Basically text ref count needs to exist at least on the vnode which owns the actual v_object.

@pho I'll post a separate fix for the panic exposed by unionfs7.sh, which just amounts to unionfs_open() not correctly accounting for the vnode being locked shared on the loader path.

From what I can tell, the main reason that managing v_writecount on the unionfs vnode might be useful would be in handling vflush(WRITECLOSE).
But WRITECLOSE only seems to be used by a few filesystems in support of read-only remounts, and unionfs isn't one of them. It's entirely possible I've missed something here, but if I can get away with it this seems like a useful simplification.

ping

Remove some write-only variables, add locking commentary

style tweak

Check for doomed uvp on re-lock

Remove asserts from unionfs_get_cached_vnode(), add locking asserts to unionfs_ins_cached_vnode()

Further style fixes, improve locking assertions and vnode checking

phabricator doesn't make it very clear, but the locking and style changes are 2 different commits.

In D32148#725684, @pho wrote:

I got this panic while testing with D32148.95756.diff:

panic: vn_lock: error 16 incompatible with flags 0x82400
cpuid = 1
time = 1632729527
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0141a13740
vpanic() at vpanic+0x187/frame 0xfffffe0141a137a0
panic() at panic+0x43/frame 0xfffffe0141a13800
_vn_lock_fallback() at _vn_lock_fallback+0xd6/frame 0xfffffe0141a13860
_vn_lock() at _vn_lock+0x86/frame 0xfffffe0141a138c0
unionfs_nodeget() at unionfs_nodeget+0x719/frame 0xfffffe0141a13960
unionfs_lookup() at unionfs_lookup+0x63b/frame 0xfffffe0141a13ab0
VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0x5a/frame 0xfffffe0141a13ad0
vfs_cache_lookup() at vfs_cache_lookup+0xa6/frame 0xfffffe0141a13b20
VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x5a/frame 0xfffffe0141a13b40
lookup() at lookup+0x4d1/frame 0xfffffe0141a13be0
namei() at namei+0x379/frame 0xfffffe0141a13c90
kern_frmdirat() at kern_frmdirat+0x15e/frame 0xfffffe0141a13e00
amd64_syscall() at amd64_syscall+0x147/frame 0xfffffe0141a13f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0141a13f30

https://people.freebsd.org/~pho/stress/log/log0182.txt

Set SAVEBANE in unionfs_lookup() instead

In D32148#725527, @mjg wrote:

You should be able to add the flag within the bowels of unionfs.

I do have a question here:
Instead of taking this approach, would it be acceptable to simply change kern_frmdirat()/kern_funlinkat() to pass SAVENAME to namei()?
unionfs might of course be the only FS that would make use of the name buffer in those cases, but it seems like a straightforward change.

Remove unintentionally added line from a different commit

Also free the vnode cache hashtable

Based on my reading of namei(9) and the code, it seems like what I'm doing here (directly passing the pathname buffer) should be OK.
During testing I also instrumented the unionfs code to verify that the lower layers weren't altering the contents of cn_pnbuf. But being new to namei, I also wouldn't be surprised if this approach is problematic for reasons that aren't apparent to me. If so, I'll go back to allocating duplicate buffers for the unionfs lookup.

Add comment on (lack of) synchronization for counters, clarify sysctl description

Clean up error handling logic, properly release the mount on error in the blocking case

Split PCATCH into a separate commit

Add sysctl node for managing deferred unmount behavior

In D31016#704531, @pho wrote:

In D31016#704507, @kib wrote:

In D31016#704447, @pho wrote:

All done. No problems seen.

20210722 19:00:47 all.sh done, elapsed 2 day(s), 04:40.10

And no nullfs issues observed? I am confused.

Yes, sorry. What I should have stated was that all of the stress2 tests were run, excluding known problem tests.
Specifically the force4.sh test, a nullfs / mdconfig -o force test, was excluded. This test failed before this patch and also fails with this patch.
I have lately tested a separate patch (by you) combined with D31016.92436.diff that fixes the issue seen with the force4.sh test. This combo is still being tested.

Prefix new fields with mnt_, MNT_TASKQUEUE -> MNT_DEFERRED

Split into multiple commits

Rebase

In D31016#702390, @mckusick wrote:

Suggestion on how to run forcible unmount test on UFS.

Fix whitespace, reap MNTK_MARKER, remove fsfail_task and add associated test

In D31016#701737, @mckusick wrote:

@jah - are you ready to have Peter Holm test these changes? If so, I will enlist his help.

Simplify by requiring taskqueue unmounts to be recursive

--Make forced taskqueue unmount operations resilient to spurious failure

A concurrent unmount attempt from another thread (which may fail) or a
concurrent update mount may induce a spurious failure.  Allow the
tasqueue to requeue the unmount request in these cases.

This is a first draft of the change; I've tested it enough to verify that it works, but I'd like feedback on the basic approach as well as some specific questions I have below.

Use STAILQ_FOREACH_SAFE to simplify the release loop

Use only CTLFLAG_RD

In D30748#691844, @jah wrote:

In D30748#691598, @jah wrote:

In D30748#691212, @mjg wrote:

If memory serves unionfs panics on mount if DEBUG_VFS_LOCKS is enabled, but the patch needs to be tested with it. I don't remember what stands in the way of fixing it, but bare minimum the triggering assert can be commented out for testing.

I didn't know we had DEBUG_VFS_LOCKS. My guess is that unionfs under stress will fail these checks in a variety of ways, but hopefully none of them will be caused by this change. This seems like another useful tool for evaluating unionfs, so I'll give it a shot as soon as I get some time.

Surprisingly, the panic on mount (new vnode not exclusively locked for insmntque()) is the only issue I've found in testing with DEBUG_VFS_LOCKS so far.

Quiesce the taskqueue on module unload