- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Oct 24 2021
Oct 21 2021
Oct 20 2021
Oct 17 2021
Oct 14 2021
Oct 13 2021
Sep 27 2021
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
Sep 26 2021
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.
Sep 24 2021
Sep 19 2021
Remove unintentionally added line from a different commit
Also free the vnode cache hashtable
Sep 12 2021
Sep 1 2021
Aug 30 2021
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.
Aug 20 2021
Aug 15 2021
Add comment on (lack of) synchronization for counters, clarify sysctl description
Aug 13 2021
Aug 12 2021
Aug 10 2021
Clean up error handling logic, properly release the mount on error in the blocking case
Aug 8 2021
Split PCATCH into a separate commit
Add sysctl node for managing deferred unmount behavior
Aug 7 2021
Jul 24 2021
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.10And 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.
Jul 19 2021
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
Jul 15 2021
In D31016#701737, @mckusick wrote:@jah - are you ready to have Peter Holm test these changes? If so, I will enlist his help.
Jul 14 2021
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.
Jul 10 2021
Jul 4 2021
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.
Jun 29 2021
Jun 18 2021
Use STAILQ_FOREACH_SAFE to simplify the release loop
Jun 16 2021
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.
Jun 15 2021
Quiesce the taskqueue on module unload
In D30748#691785, @kib wrote:In D30748#691607, @jah wrote:In D30748#691229, @kib wrote:I think it is useful, if not required, to drain the taskqueue on unmount.
This could be helpful in making it more likely for non-forced unmounts to succeed if there have been very recent deletions. Would you consider that a requirement?
My motivation for the suggestion was that the module cannot be unloaded until taskqueue is drained, and it is logical to drain on unmount to ensure that unmount is actually completed, i.e. as much resources related to the filesystem is freed as possible.
But now I think that also you need to terminate and clean up the taskqueue thread on vfs module unload.
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.
Jun 14 2021
In D30748#691229, @kib wrote:I think it is useful, if not required, to drain the taskqueue on unmount.
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.
Jun 13 2021
FIFO processing for the deferred list
Use dedicated taskqueue, use STAILQ_CONCAT to reduce list locking
Jun 12 2021
This is a naive approach. Instead of using a taskqueue, would I be better of with something completely different? For example, could I just stop holding a reference to the parent and instead lookup the parent through namei in the relatively small number of cases where unionfs needs the parent? Or, if the taskqueue is an acceptable approach, should I instead use a dedicated taskqueue instead of funneling everything through taskqueue_thread?
Jun 6 2021
May 30 2021
In D30556#686216, @markj wrote:In D30556#686194, @jah wrote:This is the same change you've already reviewed, with 2 exceptions:
--explicit inclusion of sys/types.h for _KERNEL builds from sys/mount.h, to avoid relying on coincidentally getting the header from elsewhere.
--inclusion of stdbool.h for libprocstat modules whose use of kernel headers otherwise defeats the definition of type bool.For the second issue, I would be willing to drop the libprocstat changes and instead use _Bool in VFS_QUOTACTL() if anyone insists on it. However, my personal preference is strongly for 'bool' over '_Bool' as a matter of style, and we seem to be slowly standardizing on 'bool' in the kernel. My take is that we shouldn't need to warp KPIs in order to accommodate userspace code that does sketchy things with kernel headers, especially when the code doing said sketchy things can employ a simple workaround.
I tend to agree that we should avoid mixing _Bool and bool in the kernel. It's just confusing. The change you proposed is ok with me, with the caveat that a similar modification may be needed in a small number of ports that do something like libprocstat (lsof is the main one that comes to mind). I'm ok with kib's suggestions as well.
This is the same change you've already reviewed, with 2 exceptions:
--explicit inclusion of sys/types.h for _KERNEL builds from sys/mount.h, to avoid relying on coincidentally getting the header from elsewhere.
--inclusion of stdbool.h for libprocstat modules whose use of kernel headers otherwise defeats the definition of type bool.
May 29 2021
May 25 2021
Add comments around unbusying requirements, chase __FreeBSD_version changes
Superseded by https://reviews.freebsd.org/D30401
Superseded by https://reviews.freebsd.org/D30401
Remove stray newline
Add and tweak various asserts
May 23 2021
May 21 2021
unbusy the unionfs/nullfs mount before calling QUOTACTL on the lower FS