Quiesce the taskqueue on module unload
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jun 15 2021
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
May 17 2021
In D30218#680984, @jah wrote:Add basic fixes for nullfs and unionfs, conditionalize ZFS changes
Add basic fixes for nullfs and unionfs, conditionalize ZFS changes
May 16 2021
May 15 2021
May 14 2021
Replace vfs_ref() with simple atomic load of v_mount
May 13 2021
Fix manpage formatting, remove leftover include, fix incorrect deleted line due to fingerslip
Chase D30218
Allow the implementation to direct busy state changes
In D30152#678936, @markj wrote:Do you plan to revise this change after changing the VFS_QUOTACTL interface? I'm just not sure whether to wait until that's done before re-reading this.
May 12 2021
Use correct variable when passing through VFS_QUOTACTL
May 11 2021
Follow the unbusy requirements for vfs_quotactl()
May 10 2021
Style
May 7 2021
Use atomic_load_ptr to enforce single load of vp->v_mount
Apply vfs_busy, minor refactoring
In D30152#677009, @kib wrote:In D30152#677007, @jah wrote:In D30152#676937, @jah wrote:A simpler approach would be to directly store the underlying mount objects in struct unionfs_mount, vfs_ref() them on mount and vfs_rel() them on unmount.
But that would have the effect of blocking forcible unmount of the underlying filesystems in vfs_mount_destroy(). Meanwhile, the underlying FS' vnodes would still be flushed before this happens so the underlying filesystems would be no more usable than they are with this approach.In D30152#676980, @kib wrote:Taking a reference on the mount point does not prevent unmount. For instance, calling VFS_QUOTACTL() requires busying mp, which, if successful, prevents unmount until unbusy. In fact, busying fs is currently enforced by VFS_QUOTACTL protocol since UFS (the only actual quotactl provider) in some cases unbusies and then busies the mp.
It certainly doesn't prevent the unmount operations (vflush, etc) from happening, but doesn't it prevent the unmount system call from returning? That's what I observed in testing, and is corroborated by reading vfs_mount_destroy().
Why 'preventing syscall from returning' matters? What matters is that unmount destroys the private mount data pointed to by mnt_data. This data is usually vital for VFS_XXX() methods, and destroying/freeing it while these methods operate causes undefined behavior, a crash in the best case.
In D30152#676937, @jah wrote:A simpler approach would be to directly store the underlying mount objects in struct unionfs_mount, vfs_ref() them on mount and vfs_rel() them on unmount.
But that would have the effect of blocking forcible unmount of the underlying filesystems in vfs_mount_destroy(). Meanwhile, the underlying FS' vnodes would still be flushed before this happens so the underlying filesystems would be no more usable than they are with this approach.
May 6 2021
A simpler approach would be to directly store the underlying mount objects in struct unionfs_mount, vfs_ref() them on mount and vfs_rel() them on unmount.
But that would have the effect of blocking forcible unmount of the underlying filesystems in vfs_mount_destroy(). Meanwhile, the underlying FS' vnodes would still be flushed before this happens so the underlying filesystems would be no more usable than they are with this approach.
Mar 31 2021
Mar 27 2021
Adjust wording in comment, rearrange return value assertion
Mar 21 2021
Mar 17 2021
Mar 16 2021
Mar 14 2021
Mar 13 2021
Fix la57 table accounting
--remove unnecessary include
--add la57 bootstrap accounting
--further cleanup to improve code reuse
Revert accidentally-committed PCID counter removal, incorporate resident_count
Mar 10 2021
Mar 9 2021
Mar 3 2021
In D28923#650048, @kib wrote:I probably should have been more explicit, I proposed to drop the pt_page_count at all. But I hope that you will follow up with pmap_pt_page_alloc() patch so this does not matter much.
- Revert "Remove PCID save count, factor out PT page allocation/freeing"
- Fix NULL check in pmap_large_map_getptp_unlocked()
Mar 1 2021
- Remove PCID save count, factor out PT page allocation/freeing